Re: Migrating svn to git with heavy use of externals

From: Roman Shaposhnik <rvs@sun.com>
Date: Apr 9, 2008, 03:03 UTC
Message-ID: <8FE3B7A7-4C2D-4202-A5FC-EBC4F4670273@sun.com>
In-Reply-To: <32541b130804081401n743f39c9o3f016da9dee2eb92@mail.gmail.com>

On Apr 8, 2008, at 2:01 PM, Avery Pennarun wrote:

> The way to understand git-submodule's operation is in terms of what it
> actually does.  Roughly speaking, git-submodule-add puts things into
> .gitmodules and .git/config;

I could be mistaken, but I don't think "git submodule add" does anything to the .git/config. In fact, how settings migrate between .gitmodules and .git/config has been a long standing source of slight confusion for me.

Please correct me if I'm wrong, but it seems that the only reason for the file .gitmodules to be there at all is because it can be revved through commits, just as any file under Git's control. .git/config doesn't have such a property. Other than that, it is not really needed, right?

> In other words, git-submodule is very powerful, but also very
> complicated,

Speaking of complications, it took me awhile to realize that 90%
of the Submodule magic seems to be based on the secret ability of
tree objects to hold references not only to blobs and trees but
also to *commits*:
     $ git init
     $ mkdir foo ; cd foo
     $ git init
     $ touch file
     $ git add file
     $ git commit -mInit
     Created initial commit 5a61c46: Init
         0 files changed, 0 insertions(+), 0 deletions(-)
         create mode 100644 file
Now observe:
     $ cd ..
     $ git add foo
     $ git ls-files --stage
     160000 5a61c4698ca56004c2532ce02e6736cfd2e977d1 0	foo
The  '5a61c46' is simply a reference to the commit we've just created.
Of course, it is  insufficient to know what commit "foo" refers
to unless we also know what Git repo this commit resides in. And that's
where the mapping between a path ("foo") and  a url pointing to
the submodule comes into play.

This is a cool property and it lets you build functionality like "git submodules" in a variety of different ways. I just wish it was documented somewhere.

Show 7 quoted lines

> Anyway, in this case, what you need to know is that .git/config
> already contains your submodule information.  Sadly, .gitmodules is
> probably sitting somewhere on your original branch, so it probably
> doesn't exist.  You could remove the entry from .git/config by hand
> and use git-submodule-add again (thus putting it in both places), or
> copy the .gitmodules file from the original branch, or git-cherry-pick
> the commit where you added it.

That's exactly what makes me doubtful about .gitmodules being the best place for storing the url, but then again, I don't have any better ideas. :-( Yet ;-)

Thanks, Roman.