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

Mark Levedahl [off-list ref] writes:

My use really is a different use-case than is typical....

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.

If you need explicit name, you do not have to use "origin".

You can spell URL explicitly to name which exact repository you
mean to reach over which datapath (one physical host may have
different name depending on the network interface you reach it
via).  You can always say

	$ git pull git://that.exact.machine/repo that-branch

if you want to avoid ambiguity.

And that is not atypical at all.  Scan the kernel mailing list,
looking for "please pull" requests.  You will never see 'origin'
or any short nickname.  The names used in communication should
be unambiguous in the context of the communication.  If you know
'origin' mean different things to different people, do not use
that in public communication.

It's that simple.  Isn't it?

Junio C Hamano wrote:

Mark Levedahl [off-list ref] writes:


  
It's that simple.  Isn't it?

  

Yes, until you hit submodules whose state you are managing from a super 
project. Then it gets hard because the machinery brings origin into play.

Mark