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

From: Junio C Hamano <[email-masked]>
Date: Fri, 11 Jan 2008 22:03:38 -0800

Mark Levedahl <[email-masked]> 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?