Re: [PATCH] Teach remote machinery about remotes.default config variable

Mark Levedahl <mlevedahl@gmail.com> writes:

If it is truly only about "submodule update" then the change seems too intrusive, especially "remotes.default" variable that affects the way how fetch and merge works in situations that do not involve submodules.

If it is not limited to "submodule update" but equally valid fix to non-submodule situations, the changes to the other parts may very well be justifiable, but that would mean your "Yes" is a lie and instead should be "No, but these situations are helped by these changes because...".

In any case, let's step back a bit.

Earlier you said in a response to Dscho that your servers are named consistently across repositories. servername.foo.bar has nickname servername everywhere.

If your top-level repository needs to access a specific server "frotz.foo.bar" for updates, then you would have bootstrapped the whole thing with:

	$ git clone git://frotz.foo.bar/toplevel.git

and in that particular instance of the repository, the source repository on frotz.foo.bar would have been known as 'origin', right? I would not object if you also gave another nickname 'frotz' to the same repository for consistency across developers.

If that is the case, I am wondering why your subprojects are not pointing at the corresponding repository on that same 'frotz.foo.bar' machine as 'origin'. I suspect the reason is that .gitmodules do not say 'frotz.foo.bar' but name some other machine.

And in-tree .gitmodules can name only one URL, as it is project global and shared by everybody. There is no escaping it.

At least as things were designed, "git submodule init" takes URL recorded in .gitmodules as a hint, but this is for the user to override in .git/config in the top-level. Maybe the UI to allow this overriding is not easy enough to use, and your submodules ended up pointing at wrong (from the machine's point of view) URL as 'origin'. And perhaps that is the root cause of this issue?

I am looking at the discussion on the list archive when we discussed the initial design of .gitmodules:

    http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47502
    http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47548
    http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621

I do not think we are there yet, and suspect that the current "git submodule init" does not give the user a chance to say "the URL recorded in the in-tree .gitmodules corresponds to this URL in this repository for administrative or network connectivity or whatever reasons".

Maybe that is the real issue that we should be tackling. I dunno.

Although I _think_ being able to use nickname other than hardcoded 'origin' for fetch/merge is a good change, if my above suspicion is correct, that change alone would not make the life easier to people who _use_ submodules, as the need for them to set up extra nicknames (like 'frotz') and configure the submodule repositories to use that specific nickname instead of 'origin' would not change.

For communication purposes, I would agree with Dscho that the name 'origin' that names different things for different people is wrong and using specific name 'frotz' would solve communication issues. But when using the repository and doing actual work, wouldn't it be _much_ better if you can consistently go to a repository on a random machine and always can say 'origin' to mean the other repository this repository usually gets new objects from (and sends its new objects to)?