Re: Separate default remotes for pulling and pushing

From: Jeff King <peff@peff.net>
Date: May 9, 2011, 11:10 UTC
Message-ID: <20110509111019.GD9060@sigill.intra.peff.net>
In-Reply-To: <D0FA0C3F-8DA8-4607-A0A6-F9AFAB3EC3CE@gmail.com>

On Mon, May 09, 2011 at 01:34:22AM -0700, David Lee wrote:

Show 7 quoted lines

> >  4. Decentralized, you're a developer that publishes work via git. You
> >     call the upstream maintainer "origin", so fetches are convenient
> >     (and git does this for you at clone, after all). But pushing, even
> >     though you probably always push to the same central, does not have
> >     a convenient shorthand.
> 
> By "push to the same central", I assume you mean "push to the same mirror of origin".

Yeah, sorry, that was supposed to be "central spot", but I think you got the meaning.

> I think github is making option 4 the dominant use case. In fact, in
> our workplace we have a similar workflow set up, where we pull from a
> central origin, but push to individual mirrors from where commits are
> reviewed, tested, and merged unto origin.

Yeah, I think we will see more of that as decentralized workflows (and the tools that support them) mature.

With respect to supporting an alternate default push destination, I'm not sure what is the best change to make. If "origin" were simply the default, I would say we should have a push.defaultRemote config that lets you specify something else.

But it's not that simple. If you are on branch "foo", and you have "branch.foo.remote" set in your config, then the value of that config option becomes the default remote. Which makes some sense for pulling (and there is the associated branch.*.merge config), but of course pushing may not match.

But now we have precedence questions. If I have config like:

  [push]
    defaultRemote = my-mirror

  [branch "foo"]
    remote = origin
    merge = refs/heads/master

which remote should be the default for "git push"? Obviously if I'm not on "foo", it should be my-mirror. But if I am, should push.defaultRemote take precedence? Should there also be a branch.*.pushRemote config that takes precedence over branch.*.remote?

I have to admit that I have never found the branch.*.remote config to be useful for any of my workflows, so I am not really sure how people use it.

-Peff