Re: Allowing override of the default "origin" nickname

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

On Jan 11, 2008 8:52 AM, Johannes Schindelin [off-list ref] wrote:

quoted

IMHO you should optimise the communication by agreeing on one origin,
or alternatively not talk about a server at all (which is made easy by the
global uniqueness of commit names; just say "my tip is ac9b7192").

We *cannot* agree on one definition of "origin": there is no single
server accessible by all, but use of submodules currently *requires*
that each repo's upstream be given the nickname "origin". With this
change, I can enforce that each server has a unique nickname and that
one unique nickname per server is used across the program. Absent
this, I cannot and end up having to have everyone translate "origin"
into what it means for them.

SHA-1's are absolutely unique, but what do you do when "origin" does
not have  acdc101? I want to know that server-x@joe.com doesn't have
it, while server-y@mary.org does. This is the frequent problem in
conversation, and is the reason we have to be able to talk about the
particular upstream server.

This change does not eliminate the ability to obscure multiple
different server names using "origin" for those who think that is the
best way to do things, it just eliminates the requirement for doing
so.

Dscho, although I can agree that more flexibility is not always a good
thing, I think that in this situation it is a good thing. I especially
like that git-clone remembers what name it used for upstream repository
(git clone --origin <name>).

Mark, if this change is mainly about the fact that git doesn't allow
to specify default remote to fetch for detached HEAD (and submodules
use detached HEAD), why not provide "branch.HEAD.remote" etc., which
would be used _only_ if we are on detached HEAD (i.e. branch has no
name).

-- 
Jakub Narebski
Poland
ShadeHawk on #git