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
-
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
