Separate default remotes for pulling and pushing

Hello,

I couldn't find a way to do this, but it seems it would be a fairly common use-case:

I want to set up different default remotes for pushing and pulling so that I can pull from remote a using "git pull" and push to remote b using "git push". This is particularly useful when committing to projects on github, since you may only push to your fork, but you only want to pull updates from the original.

Right now, I can either set the original as my default remote, in which case I must use "git push myfork", or I can set my fork as the default remote, in which case I must use "git pull original".

Please let me know if I'm overlooking a feature already present in git that allows me to have separate remotes for pull and push. Otherwise, I hope it gets implemented in the next version of git!

Thanks for reading, David

Heya,

On Sat, May 7, 2011 at 10:10, David Lee <davidomundo@gmail.com> wrote:

See 'git remote set-url --push' [0].

[0] http://www.kernel.org/pub/software/scm/git/docs/git-remote.html

On Sat, May 07, 2011 at 11:50:35AM +0200, Sverre Rabbelier wrote:

That probably doesn't quite do what David wants. It's useful when the URL for pushing and pulling a particular repository are different.

But if I understand it correctly, David has two _separate_ repositories. And using remote.*.pushurl for that has some unwanted side effects, because the tracking ref namespace (i.e., "remotes/origin/*") is shared by both, even though their refs may not be at the same position.

For example, when pushing "refs/heads/master" to the remote, git will update "refs/remotes/origin/master" to the pushed value. But that ref is supposed to reflect the value of the last fetch from his "original" repository, and now it doesn't. The ref value will flip back and forth between what's in the two repositories as he pushes and fetches.

I don't think there is currently a way to do what he wants. I think it would be useful for certain workflows. As I see it, there are a few pretty common setups for remotes:

  1. Centralized; you push and pull from a single repo, shared with
     other developers. In this case, you call it "origin" and everything
     is easy.

  2. Decentralized, you're the maintainer; you pull from other people or
     apply patches via email. When you push, you push out to some
     publishing point. You'd probably call your publishing point
     "origin" (though I think Junio calls kernel.org "ko" and just types
     "git push ko"). You never pull from some single place all the time,
     so you don't care about a shorthand for it.

  3. Decentralized, you're a developer with a patch-based workflow; you
     fetch from the maintainer, then develop and submit patches via a
     mailing list. You call the maintainer's repo "origin" and pull from
     it automatically.  You never push, so it doesn't matter that
     there's no shorthand.

  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.

     This is David's case (and mine, and I suspect some other git
     developers who do enough work that they want to make it publicly
     available via git, or even just have backups). It's also encouraged
     by sites like github, where you might clone the upstream's
     repository, but then pushes your changes up to a personal "fork"
     to let others see and merge them.

So I think part of the reason we don't have such an option is that cases 1-3 are so common. But it would be a nice convenience for people in case 4.

-Peff

Hey Jeff,

Thanks for the super write-up.

I was actually using Sverre's recommendation with virtually no problems except for what you mention: the ref value flips back and forth.

By "push to the same central", I assume you mean "push to the same mirror of origin".

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.

--David

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

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

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

What about removing the branch.*.remote config by default, and if it's not set, then it defaults to whatever the repo-wide setting is for defaultRemote? Then a branch.*.remote would override the defaultRemote, and a branch.*.pushRemote would again override that.

On Mon, May 09, 2011 at 12:01:53PM -0700, David Lee wrote:

The branch.*.remote config does much more, though. For example, it is part of the "upstream" branch config. So getting rid of it is definitely not an option.

-Peff

Jeff King <peff@peff.net> writes:

In a sense, this is what I do as well. As you mentioned, I push to "ko" to publish, but when I "fetch" (or "pull") from "origin", I get the public copy I have at kernel.org like everybody else, and I do fetch every time after I push to "ko" to get the updated preformatted HTML and man page branches.

I never felt it awkward that my fetch says "origin" and my push says "ko". Even though I imagine that I could smash them together into a single "origin", it would not give me anything, as I also push to push to different places like repo.or.cz, sourceforge and github anyway.

While I see why some people might want to say "origin" for both in such a set-up (when they do not push to multiple places like I do), I have a feeling that it is a misguided wish that would make themselves unnecessary confused than they already are, especially if the repositories used for pushing and fetching are in reality different repositories (one good example why it would be confusing is how remote tracking branches are updated).

On Mon, May 09, 2011 at 09:45:49AM -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?

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.

But this is all definitely a minor convenience. It is not that world-shattering to type "git push my-fork", nor "git push my-fork && git push my-backup". Probably twice a week I accidentally try to push to "git://git.kernel.org/pub/scm/git/git.git", but git make it clear that is not allowed. :)

-Peff

Jeff King <peff@peff.net> writes:

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.

I say "git push ko", take a sip of tea, and after k.org finishes the asciidoc dance "git fetch ko" to get them all, before pushing remotes/ko/{maint,master,next,pu,todo,html,man} to secondary sites.

Either we add branch.<name>.pushremote or push.defaultremote then?

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

Ah, that makes sense.

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

On Mon, May 9, 2011 at 6:04 PM, Jeff King <peff@peff.net> wrote:

While developing in a particular repo, I constantly have to push to two compile machines. I just dropped a Makefile into the top of my working tree:

all: push
amend:
	git amend -a
	git --no-pager diff @{1}
	make push
push:
	make -j 2 mac win
mac:
	git push mac
win:
	git push win

j.

On Tue, May 10, 2011 at 08:47:53AM -0400, Jay Soffian wrote:

Yeah, I have scripts to help with that sort of thing now. But that is often an unsatisfactory solution, because either:

  1. Your Makefile is not version-controlled.

  2. Your are polluting the project history with stuff specific to your
     workflow. I would not get very far proposing that git.git's
     Makefile contain such a thing. :)

That's how Junio ended up with his "Meta" directory (and I have one, too, but with drastically different things in it).

-Peff

On Tue, May 10, 2011 at 4:20 PM, Jeff King <peff@peff.net> wrote:

Sure, but your .git/config is similarly not version controlled.

As well. :-)

j.