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

Junio C Hamano wrote:

"Mark Levedahl" [off-list ref] writes:
  
Thanks.

I have to admit that I happen to agree with Dscho.  I do not see
this helping to solve communication issues very much.
  

Junio,

My use really is a different use-case than is typical. Origin is a great 
concept for the common case of projects with a single upstream 
repository. Except for cloning, you don't have to know or care the name 
of the upstream as you move from project to project, it is just always 
"origin" and you use the same remote nickname in each.

This breaks down in a project like mine where there are multiple servers 
and the differences are important. Content and usage vary server to 
server, not just connectivity. At this point, hiding the server names is 
counterproductive. Basically, use of origin is data hiding, and data 
hiding is not good when you actually need the data.

Across the git project, I believe everyone basically understands origin 
as git.kernel.org/..., and origin is not ambiguous. There is just one 
server. For my project, there are multiple servers and a number of us 
pull from and push to multiple servers with no intent that any one 
server has everything (This multiplicity is necessary for several 
reasons, and we have various guards in place restrict the content of 
different servers). Thus, there really is no usefully defined *origin*. 
There just isn't. This is where the disagreements lie.

The argument against my approach of explicitly naming the server rests 
upon the premise that hiding a half-dozen servers, all different and 
with those differences being important, under the single universal name 
"origin", makes things easier. It doesn't when different servers are 
different. Yes, it is possible to figure out what "origin" means at a 
given client, and thus understand how to address a given server from 
that client. That is the essence of the problem. It is clear to address 
server1 as "server1", and server3 as "server3." It is not helpful to 
sometimes refer to server1 as origin, sometimes as server3, and thus 
need to know the definition of origin to know how to name the server. 
For the "normal" git use-case the specific definition of origin is 
unimportant when you use it and so provides a useful abstraction. That I 
must know what origin means in order to know what to do indicates the 
abstraction is counter-productive.

Until we started using sub-modules, we used git clone --origin 
<nickname> and per our standard usage never even had "origin" defined. 
We just agreed on a common set of nicknames for our servers and used 
those. Not everyone had all the remotes defined, but nickname "foo" 
meant the same thing everywhere it was defined. That worked very well 
for us.

So, all I am doing here is trying to extend a basic multi-server 
capability git already has for a monolithic project into projects using 
sub-modules. This will let us resume working the way we did before and 
stop overloading a single nickname (origin) with multiple meanings.

Mark