Git Submodule Usage Pattern

Git Submodule Usage Pattern

[Tim Visher]

Hello Everyone,

I recently found a case where I thought submodules would be a perfect
fit.  I confess that I don't fully understand how submodules are
supposed to work.  The [section in the Pro Git
Book](http://progit.org/book/ch6-6.html) is fairly explanatory but
also seems to be very cautionary.  The man page also is a little
cryptic, sort of like submodules really aren't supposed to be used all
that often, which I think is indeed the community feeling.

That being said, I wanted to include the [zen-and-art color
theme](http://github.com/irfn/zen-and-art) in my .emacs file and since
it is already a git repo, I figured that it's the perfect case for a
submodule.  Now I ran into a problem.

I have the following configuration typically.  My main box at home
will point at GitHub if I have a public repo, as I do with my .emacs
file.  I then also sync with 2 other locations, a Backup directory for
safety's sake and a USB stick.  The stick repo is so that I have a
place to sync to if I have to work behind a firewall, as I do at work.
 I want to not have to remember to sync to 2 places from home so that
I can work at work and I don't feel like writing a script that would
allow me to not have to remember it (although that is, admittedly, one
solution to my problem).  The solution I came up with was to have my
work repo clone via `http://` from GitHub (that would be `origin`) to
get the latest changes I made at home, but then push to my Stick if I
needed to do any emergency work so that my home location could grab
those changes and then push them out to GitHub.  Obviously at home I
would just be pushing and pulling from GitHub.

So that's:

                     GitHub
                    /   ^ \
                   /   /   \
                  /   /     \
              --git://--     \
                /   /       http://
               /   /           \
              /   /      ---firewall---
             /   /               \
            v   /                 v
           Home Box              Work
         /       ^ \              /
   file system  file system      /
       /           \ \          /
      v             \ v        v
    Backup          ----Stick----

---aside---
For those of you reading mail in a sucky reader like GMail (as I am)
that ASCII art got pretty well screwed.

I posted a picture of it
[here](http://random.burningones.com/gitSubmodulesWorkflow.png).

Sorry…
---aside--

This works great because remotes are configured on a per-repo basis.
My origin at work points where it needs to and my origin at home does
the same.  Now comes the confusion.

Apparently, submodules are not configured on a per-repo basis, unless
I'm totally misunderstanding something.  The .gitmodules file wants to
be checked in just like .gitignore, etc.  I don't know if submodules
will work correctly without syncing that between repos, either.  What
I need is to have the submodule at work point at a different repo than
the submodule at Home to avoid firewall issues.  Or for someone to
suggest a different work flow that would allow me to have my main home
repo point at GitHub using my private git:// address and the
zen-and-art repo using it's public git:// clone address and then have
my Work repo clone from GitHub around the firewall (or somewhere else,
GitHub's http cloning is still pretty Janky) but then push to the
Stick.

Thanks in advance for your thoughts.

-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail

Re: Git Submodule Usage Pattern

[Avery Pennarun]

On Tue, Feb 16, 2010 at 9:39 AM, Tim Visher <tim.visher@gmail.com> wrote:
> Apparently, submodules are not configured on a per-repo basis, unless
> I'm totally misunderstanding something.  The .gitmodules file wants to
> be checked in just like .gitignore, etc.  I don't know if submodules
> will work correctly without syncing that between repos, either.  What
> I need is to have the submodule at work point at a different repo than
> the submodule at Home to avoid firewall issues.  Or for someone to
> suggest a different work flow that would allow me to have my main home
> repo point at GitHub using my private git:// address and the
> zen-and-art repo using it's public git:// clone address and then have
> my Work repo clone from GitHub around the firewall (or somewhere else,
> GitHub's http cloning is still pretty Janky) but then push to the
> Stick.

Three suggestions I can offer:

1) After running 'git submodule init', look in .git/config.  You can
change which repos the submodules point to from there, on a per-repo
basis, and not affect other people's checkouts.

2) Try using relative repo paths (like ../foo.git) in .gitmodules.
Then as long as your repositories are siblings of each other, if you
can check out one you can check out the other.

3) git-subtree (http://github.com/apenwarr/git-subtree) does not
exhibit this problem.

Have fun,

Avery

Re: Git Submodule Usage Pattern

[Andreas Krey]

On Tue, 16 Feb 2010 12:48:16 +0000, Avery Pennarun wrote:
...
> Three suggestions I can offer:
...
> 2) Try using relative repo paths (like ../foo.git) in .gitmodules.

Is that a 'try', or are those supposed to work?

4) Use

  [url "git@github.com:apk/"]
      insteadOf = "git://github.com/apk/"

in ~/.gitconfig allows changing the the actual url used. I use that
to be able to clone seemingly with the public github url but still
be able to push. You can use that to let an submodule point to
some other place where there is a clone of the submodule repo,
or another access method.

Andreas

Re: Git Submodule Usage Pattern

[Avery Pennarun]

On Tue, Feb 16, 2010 at 3:00 PM, Andreas Krey <a.krey@gmx.de> wrote:
> On Tue, 16 Feb 2010 12:48:16 +0000, Avery Pennarun wrote:
>> Three suggestions I can offer:
> ...
>> 2) Try using relative repo paths (like ../foo.git) in .gitmodules.
>
> Is that a 'try', or are those supposed to work?

It works.  The reason I said "try" is that in order to *make* it work,
you may have to move your repositories around so that you can reach
one using a relative path from the other (ie. it's easiest if they're
on the same server at the same level of the directory hierarchy).

Avery