Re: Separate default remotes for pulling and pushing

[Jeff King <peff@peff.net>]

On Mon, May 09, 2011 at 03:46:19PM -0700, Junio C Hamano wrote:

> > Interesting. Is your fetch from "ko" a no-op, or are you using it to
> > syncrhonize development between different machines?
> 
> Preformatted html and man pages are made when I push the integrated source
> branches out, triggered from the post-update hook at kernel.org.  I do not
> format them on my box.

Ah, that makes sense.

> > I think it is important to note that calling them both "origin" is
> > definitely the wrong thing. The proposal is instead that "git push"
> > without a remote would default to something besides "origin". For people
> > who publish multiple places, it might even make sense for it to be an
> > iterative push to each place.
> 
> Either we add branch.<name>.pushremote or push.defaultremote then?

I don't think most people would want just branch.<name>.pushremote. They
are more likely to want to always push to some place, so
push.defaultremote is a better choice.

But that has weird precedence problems. We auto-create branch.*.remote,
so if branch-specific config takes precedence, their push.defaultremote
will almost never be used. And if branch-specific config _doesn't_ take
precedence, then that is weird and unlike almost every other part of
git.

Another option is to mark the remote with an explicit "don't push here,
push to this other remote instead" config, like:

  $ git remote add my-fork host:project.git
  $ git config remote.origin.pushremote my-fork
  $ git push ;# acts as if you did "git push my-fork"

And then when we default to a remote, either because it is "origin" or
because it is in branch.*.remote, then we will end up pushing to the
right place.

I'm unsure what should happen in the case of:

  $ git config remote.origin.pushremote my-fork
  $ git push origin

In the workflow we described, "origin" is simply not a push-able remote,
so it is a slight convenience to intercept all pushes for it and
transparently rewrite them to "my-fork". And it makes the concept of
that config slightly simpler. It basically becomes the equivalent of
remote.*.pushurl, except that we are clear that it is a totally separate
remote with different tracking branches.

But it does eliminate any workflow where "origin" is _sometimes_
pushable, but you almost always want to push somewhere else instead.
Because you have no way to push to "origin" now. I don't know of any
such workflow, but I hate to be restrictive for no good reason.

If it just handles "use this remote instead only in the case of a
default selection", then the name should probably be like
"defaultpushremote" or something.

-Peff