Re: Migrating svn to git with heavy use of externals

["Avery Pennarun" <apenwarr@gmail.com>]

On Tue, Apr 8, 2008 at 11:03 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> 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?

You have the last paragraph right, but I think the first paragraph wrong :)

.gitmodules doesn't do anything unless git-submodule reads it, which
it does in git-submodule-init and git-submodule-add.  (You know
git-submodule-add is screwing with .git/config because you don't need
to call git-submodule-init when you use it.)  git-submodule-update,
AFAICT, just reads .git/config.

>  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*:

Indeed, this is the majority of the coolness right there.  The rest of
the screwiness with .gitmodules and so on is really just to support
fetching the objects for the submodules from repos than the primary
supermodule one.

Also, git-checkout seems to explicitly *not* checkout refs to commits
by itself; you have to call git-submodule-update for that.  This is
probably because git-checkout wouldn't know what to do if the
submodule were dirty (ie. the sub-checkout couldn't complete because
files had been changed but not checked in).  This is useful in a
not-destroying-my-data way, but the behaviour isn't too obvious or
coherent.

>  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 ;-)

There's definitely no better place; .git/config isn't versioned, and
URLs don't belong in the tree objects themselves, which are otherwise
location-neutral and transport-neutral.

In my own use case, I think having all the objects from the
supermodule *and* submodules all be in the same repo is what I want.
This kind of obviates the need for .gitmodules entirely, if
git-checkout and friends will do the right thing.  I think I'll submit
some patches eventually once I have this figured out properly.

Have fun,

Avery