Re: [PATCH] Add git-submodule command

"Lars Hjemli" [off-list ref] writes:

On 5/25/07, Junio C Hamano [off-list ref] wrote:
...

quoted

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

I've read these articles, but I think much of the concerns about
trusting the url supplied by upstream goes away when the submodule
clone/checkout isn't an integrated part of the superproject
clone/checkout. Besides, if you trust your upstream enough to clone
their repository (the superproject), why wouldn't you trust the data
(.gitmodules) in that very repository?

It's not about trusting.  You would need to support the mapping
for network connectivity reasons, and you would also need to
notice and reconfirm when the suggested URL in .gitmodules
changes (perhaps because the upstream relocated from sf.net to
repo.or.cz ;-), you would need something like what I described
in order to keep track of user preference for each submodule in
.git/config anyway.  If that "mapping" ends up to be ident
mapping for most people, that is fine.  At least by always doing
the three-level mapping we would not have any special case in
the code, and this is not the performance critical part of the
system.

I think the response to the case when upstream repository
relocates from the ".gitmodule for default, .git/config for
override" camp would be "you asked to override in .git/config,
so it is your job to notice the change in .gitmodules and adjust
your override URL".  That is a serious mistake in usability
point of view.  Repository relocation would (hopefully) seldom
happen, but when it does happen, things either would break
(which is easier to diagnose and manually fix up), or things
clone fine but we reach a wrong repository (which is harder to
notice, as "fetch" may succeed -- it just would not fetch the
right commit).  Being able to notice when upstream repository
relocates and to ask for confirmation when that happens would
eliminate a lot of confusion from that.

Another possibility is simply doing the submodule clone/checkout by
hand (i.e. do 'git clone preferred-url path', don't do 'git submodule
init path').

But that is what this patch is trying to help the users, isn't
it?  It reduces the attractiveness of this new tool greatly if
you give up there.

quoted

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.

I really can't imagine what kind of superproject would have such a
setup. Why would this be needed?

"We would work with any working version of Linux 2.6 kernel"
would be a sensible thing to say, I would think.

It's purely optional, and as you seem to agree always detaching
HEAD is easier to explain, you do not need "module.$path.branch"
at all.  I just mentioned 0{40} as a possible use case for that
configuration variable.