Re: [PATCH 0 of 7] [resend] - Improve handling remotes, origin, submodules

"Mark Levedahl" <mlevedahl@gmail.com> writes:

I think you misunderstood Dscho's $HOME analogy.

For example, the value of HOME environment variable is used as a shorthand to where you go to when you say

	$ cd

Everybody is happy that the variable is called HOME, and nobody would complain that the shell does not have another mechanism to let you have this in your .bashrc

	#!/bin/bash
	HOMEENVVAR=BASE
	BASE=/home/mark
        export HOMEENVVAR BASE

and make the parameterless "cd" honor the environment variable named with HOMEENVVER (in this case, BASE) instead.

Remote shorthand is exactly like a variable name. We say "git pull origin" and do not say "git pull $origin", but that is just a syntax issue. And "git pull" and friends are defined to default to the value of the origin 'variable' exactly like "cd" is defined to default to the value of the HOME variable.

I would agree 100% with Dscho on this point, if we did not have "clone -o".

"clone -o" is like the above HOMEENVVAR variable. It lets you rename what name other than origin is used to name what the origin 'variable' usually names, or at least pretends to let you do so. But its effect may not extend far enough and if there is such inconsistency, that is a bug worth fixing. For example, I think "git fetch" is Ok for basic use, because "clone -o" writes branch.master.remote in .git/config that points to the name you gave instead of 'origin', but there may be places that do use hardwired 'origin' and nothing else.

And that is the only reason I am still responding to this thread.

If a supermodule wants a specific remote to be used in a submodule, it should not default to 'origin' but it should name that specific remote explicitly. Even if we added the mechanism that looks like HOMEENVVAR to tell commands other than "git fetch" to default to something other than 'origin', I do not think such a use of submodule should depend on that fallback. I still haven't dismissed Dscho's argument that submodule related issues should be handled inside git-submodule for that reason.

We could remove support for "clone -o" and consistently use 'origin' as the default everywhere and completely remove the half-baked HOMEENVVAR lookalike. I do not think such a move is a good idea, but the point is that the solution to your submodule problem should work even if we did so. If the supermodule and a set of submodules are configured to use a specific remote that is not 'origin', it should use that specific remote by _naming_ it, not relying on where the fallback value is taken by other unrelated parts of the system, no?