"Mark Levedahl" <mlevedahl@xxxxxxxxx> writes:
> BIG difference here:
> $HOME = <name> of home directory, <name> is arbitrary. Files there are
> found as $HOME/<foo> or <name>/foo, they are the same, and I am free
> to set HOME=<arbitrary name>.
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?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
