"Mark Levedahl" [off-list ref] 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?
Hi,
On Mon, 4 Feb 2008, Junio C Hamano wrote:
I would agree 100% with Dscho on this point, if we did not have "clone
-o".
AFAICT "clone -o" was meant _only_ for this scenario:
You have a slow connection, but someone can provide you with a thumb
drive, having the current repository.
You clone it from the thumb drive, but of course you want to use your
(slow) connection for subsequent updates (i.e. you want to have a
different default remote).
What you do is
$ git clone -o thumbdrive /media/usbdisk/that-repository.git/
Then, to be able to update from your preferred remote quickly, you add the
proper remote:
$ git remote add --fetch origin git://git.kernel.org/shlub.git/
In my understanding, this scenario is the only reason to live for clone's
-o option, and it would be actively wrong for it to change the _name_ of
the default remote to "thumbdrive".
Now, Steffen understood that Mark tries to avoid the use of "origin".
But why, then, does he wish for _the same_ kettle, but call it chair?
I mean, I can understand if you want to update your submodules from
another server. What I do then, is to go into that subdirectory, fetch
from that other server, and that's it.
I can even understand that you have to update your submodules sometimes
from here, sometimes from there.
Fine. You just add remotes for the different servers, cd into the
submodules, and fetch from them.
I could even see (but not use it myself) that you want to fetch a set of
submodules from server A on Mondays, from server B on Tuesdays, and from
server C on Wednesdays, and want to have a nice shortcut for that. Of
course, I'd use aliases. But I can see that people want a "--remote"
option to "git submodule update".
However, what I cannot see _at all_ is that you have a default remote in a
set (or all) submodules, and wish to change a perfectly fine terminology
[*1*].
I cannot see why you want to have a default remote to fetch from, and not
call it "origin", which would keep things easy and simple. "What is the
remote called that 'git fetch' fetches from, by default?" -- "origin".
Simple. Nice. Consistent.
My understanding is that a patch is needed for _git-submodule_, to support
that workflow (the one with servers A, B and C), even if I would not use
that option.
What we do not need is to confuse git users, what with all those
complaints that git is too complicated.
Hopefully I finally made myself clear.
Ciao,
Dscho
*1*: I heard the argument put forth that giving the default remote a
different name, so that people know what server they pull from. That's
just, uh, unbelievable. If it is the default remote the user is fetching
from, all the user will call is "git fetch", and not even _know_ the
nickname.
Besides, if you call it "berlin", the _url_ can still point to
git://git.beijing.cn/great-wall.git/.
Another besides: if you ask the user to look up the nickname of the
default remote, you can as well ask the user to look up the url of
"origin".
There is _no need_ to complicate git for a workflow that could be solved
in a more elegant and less error-prone way to begin with.
P.S.: sorry for this long mail. I usually like to make a concise point.
But in this discussion, it got me misunderstood, ignored, or both.