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

[Mark Levedahl <mlevedahl@gmail.com>]

Johannes Schindelin wrote:
> Unfortunately, you _still_ fail to even ackonwledge that you still need a 
> lookup, and that I have a point when saying "your patch does not help, 
> since you still have a lookup".
>   
I don't acknowledge this point as it is not true.

I will try to explain one more time.

1 - "origin" is fine as an abstraction IFF everyone on the project can 
reasonably expect that "git fetch origin" will yield the same results 
for anyone who executes that command. As I have tried (and apparently 
failed) to explain, for numerous complex and unchangeable reasons, "git 
fetch origin" is *NOT* expected to give the same results around this 
project and therefore, "origin" is not a useful abstraction.

2 - Until we used submodules, we never defined "origin", but instead 
explicitly named the server using standard nicknames (e.g., "git fetch 
frotz", not "git fetch"). Everyone who can access frotz gets the same 
result. Those who can't, and have to use server "zorft", get a different 
result but it is obvious to all they didn't go to frotz.

3 - As the servers are different and have different content, it is just 
part of the workflow to know the server names and use them. We have 
agreed upon a common set of server nicknames. There is no lookup, we 
just know them. Maybe you call this a lookup step, but frankly this is 
part of *required* job knowledge (which server has what and which to use 
for which purpose).

4 - The problem came with submodules. Now, the recipe of "git clone -o 
frotz" no longer really works, as all of the submodules now have remote 
origin = frotz, and remote frotz is undefined while the master-project 
is the other way around. This is confusing to say the least. As 
submodules forced origin in, the path of least resistance  was just 
giving in and using origin. Now we have to be very aware not only of 
what server to use, but now also what origin is so that we can know how 
to reach the server we wanted. (i.e., Do I use "origin" or "frotz" to 
reach frotz?) This *IS* an extra lookup step required because of origin 
being defined.

Now, we can recusively use "git remote add" to just go ahead and add all 
remotes needed regardless of what origin says, and *partly* get back to 
where we were. Only partly, because git submodule update will still use 
origin, and *only* origin for fetching. So we still have to know what 
origin is (problem #1, fixed by my patches 1-4), and if what we need to 
fetch from is in fact not origin (even though the master project knows 
what server to access), submodule update in fact doesn't even work 
(fixed by the fifth patch that flows the remote down from the master).

So no, I do not acknowledge that we have an extra lookup step and that 
just using origin is the same or simpler or whatever. It absolutely is 
not. Quite the opposite, for us using "origin" forces an unnecessary 
extra lookup and translation step and complicates, not simplifies, use 
of submodules.

Mark