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

From: Shawn O. Pearce <spearce@spearce.org>
Date: Apr 27, 2008, 04:30 UTC
Message-ID: <20080427043014.GI29771@spearce.org>
In-Reply-To: <7vzlrgmrvb.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

> "Shawn O. Pearce" <spearce@spearce.org> 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.