Re: Proposal: branch.<name>.remotepush

From: Jeff King <peff@peff.net>
Date: Feb 8, 2013, 04:48 UTC
Message-ID: <20130208044836.GC4157@sigill.intra.peff.net>
In-Reply-To: <CALkWK0nA4hQ0VWivk3AVVVq8Rbb-9CpQ9xFsSOsTQtvo4w08rw@mail.gmail.com>

On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:

Show 6 quoted lines

> This has been annoying me for a really long time, but I never really
> got around to scratching this particular itch.  I have a very common
> scenario where I fork a project on GitHub.  I have two configured
> remotes: origin which points to "git://upstream" and mine which points
> to "ssh://mine".  By default, I always want to pull `master` from
> origin and push to mine.

Same here. Even without GitHub, working on git.git I treat Junio as my "origin", but push to a publishing point.

Show 7 quoted lines

> Unfortunately, there's only a branch.<name>.remote which specifies
> which remote to use for both pulling and pushing.  There's also a
> remote.<name>.pushurl, but I get the feeling that this exists for an
> entirely different reason: when I have a server with a
> highly-available read-only mirror of the repository at
> git://anongit.*, and a less-available committer-only mirror at
> ssh://*.

Yeah, you don't want to use pushurl. It makes the assumption that you are pushing to the same remote, so when you, e.g., push to the remote's refs/heads/master, it will update refs/remotes/origin/master. But that's not right; that ref should be tracking the true origin, not what you pushed to.

> How about a branch.<name>.remotepush that specifies a special remote
> for pushing, falling back to branch.<name>.remote?

Sure, though I wonder if you really want a per-branch config, or if you just want remote.pushDefault or similar, so that you do not have to configure each branch independently as you create it. I'm imagining lookup rules something like:

  1. If we are on branch $b, check branch.$b.pushRemote.

  2. If not set, check remote.pushDefault.

  3. If not set, check branch.$b.remote.

  4. If not set, check remote.default (there was a proposal for this a
     few months ago, but it got stalled).

  5. If not set, use "origin".

And then fetching could do the same, with s/push/fetch/. In both cases, if you are not using the new variables, the behavior is the same as the current behavior.

-Peff