Re: [PATCH] Add git-submodule command

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Fri, 25 May 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Fri, 25 May 2007, Lars Hjemli wrote:
> >
> >> +FILES
> >> +-----
> >> +When cloning submodules, a .gitmodules file in the top-level directory
> >> +of the containing work-tree is examined for the url of each submodule.
> >> +The url is the value of the key module.$path.url.
> >
> > IIRC Junio talked about a name for overriding. But I think it would be 
> > even better to to override by mapping the URLs from .gitmodules to the 
> > locally-wanted URLs.
> >
> > Junio?
> 
> I really do not want that (mis)conception that .gitmodules
> specify the default and .git/config the override.  I really
> think we should use the .git/config as _the_ only authority to
> get URL, but keyed with the three-level scheme, with URL in
> .gitmodules used _solely_ as a hint when setting up the URL in
> the .git/config file.
> 
> 	cf. $gmane/47502, 47548, 47621

Yes, I skipped over the first two, and concentrated on the third. If 
.gitmodules are used to initialize what is in .git/config, I agree.

However, could we have that as a separate commit, to keep things simple 
enough so that I can understand them?

> >> +When updating submodules, the same .gitmodules file is examined for a key
> >> +named 'module.$path.branch'. If found, and if the named branch is currently 
> >> +at the same revision as the commit-id in the containing repositories index, 
> >> +the specified branch will be checked out in the submodule. If not found, or 
> >> +if the branch isn't currently positioned at the wanted revision, a checkout
> >> +of the wanted sha1 will happen in the submodule, leaving its HEAD detached.
> >
> > A very good description, and I think this is the only method to checkout 
> > the submodule which makes sense. (Just maybe default the value of 
> > module.<path>.branch to "master"?)
> 
> I suspect leaving the HEAD always detached if the superproject
> tree names a concrete commit object name would be less confusing
> and consistent.  When the name of the commit object in the
> superproject tree and/or index is 0{40}, it would be a good
> extension to use "whatever commit that happens to be at the tip
> of this branch" taken from the .gitmodules file.

Yes, that's a much better idea.

Ciao,
Dscho