Hey Jeff, Thanks for the super write-up. > 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. > 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". > > 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-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html