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 00:30:14 -0400

Junio C Hamano <[email-masked]> wrote:
> "Shawn O. Pearce" <[email-masked]> writes:
> 
> > Why not just have a remote named "my-mirror" and do `git push my-mirror`?
> > Yes, its on keystroke longer to type.  Call it foo.  `git push foo` would
> > be shorter, and not require code changes in Git.
...
>  (2) no, by separating individual remotes (which are not 'foo') and a
>      magic "pushing to everywhere" (which is 'foo'), that extra 'foo'
>      simplifies things, to explain, understand, and diagnose (when
>      something goes south).

This is the only behavior that really makes sense to me.

When I first started to learn and use a DVCS I'll admit that I did
found it odd that "$dvcs commit" did not make my changes immediately
available to everyone else on the project.  I've gotten over that
and have become very used to the idea that "git push foo" is the
means that I publish my work to location(s) named "foo", using the
publication means I have pre-configured for that name.

Not all of my work from the same repository is always published
the same way.  For example in egit I can publish to both
the master egit tree (repo.or.cz/egit.git) and to my fork
(repo.or.cz/egit/spearce.git).  I publish to the latter almost
daily, and rebase even more often than that.  But the master tree
only receives stable work whose history does not rewind.

In git being able to configure two different remotes and specifically
pushing to the destination is very easy.  What is less easy is our
reliance on a default named "origin" and the syntax we have for
the remote configuration.  It is fairly simple, but new users do
seem to struggle with it a bit.

-- 
Shawn.