Re: Separate default remotes for pulling and pushing
Hey Jeff,
Thanks for the super write-up.
Show 13 quoted lines
> 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 was actually using Sverre's recommendation with virtually no problems except for what you mention: the ref value flips back and forth.
Show 5 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".
Show 11 quoted lines
>
> 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.
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