Subject: Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

From: "Shawn O. Pearce" <[email-masked]>
Date: Sun, 27 Apr 2008 13:34:46 -0400

Junio C Hamano <[email-masked]> wrote:
> "Shawn O. Pearce" <[email-masked]> writes:
> 
> > I _hate_ the default remote. [...]
> 
> It sounds as if you want to say it a bit stronger than that --- to you,
> defaulting to 'origin' is not of "little to no" but "negative" value, is
> it?
> 
> But I think we are minotiry.  To people with "CVS migrant" workflow,
> cloning from _the_ central repo, hacking, and then pushing back will never
> involve anything other than 'origin' and local repositories, and I am
> sympathetic when they want to say "git push" and have it default to that
> single other repository.

Yes, I think we are in the minority.  Many people come to Git from
a centralized system so the idea of just a single place to pull/push
from makes perfect sense to them.

But then they later wonder why they need `git pull origin branch`
to merge in branch, when they usually just say `git pull`.  What is
the need for that funny keyword `origin`?  Why do I have to say
where to get the branch from sometimes and not others?

I think this argument is like the one we had with `git pull . branch`
vs. `git merge branch`.  However we probably could have gotten users
to accept `git merge . branch`, as the main argument there was the
fact that git-merge (the natural command to invoke) didn't actually do
what the user wanted, and git-pull did.

Just take the above as the rantings of someone who knows git a
little too well, and has tried to teach it to people who don't,
and they all have asked about the funny (to them) need for origin
in git-pull/git-push command line sometimes (no refspecs) and not
others (with refspecs).

-- 
Shawn.