On Apr 8, 2008, at 2:01 PM, Avery Pennarun wrote:
quoted text
> 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?

quoted text
> 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.

quoted text
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html