Junio C Hamano wrote: > [remote "origin"] > url = ... where Ram fetches and pulls from ... > pushurl = ... where Ram pushes to ... > fetch = refs/heads/*:refs/remotes/* > updateTrackOnPush = no > > Then "git fetch" (or "git pull") will update the remote tracking > branches Ram fetches from, and once his topic is finished, he can > push to his publishing location, which won't touch the remote > tracking branches used to keep track of the place he fetches from. A "push" should never touch remote/refs/origin/* if there is a pushurl configured. Otherwise, it should. I want my push to affect my status. The configuration variable makes no sense and should not exist. Unfortunately, pushurl doesn't get the same privileges as url even though they're equal remotes. How is my fork "inferior" to the upstream project in any way? A lot of us might be working on this fork, and we will need something corresponding to refs/remotes/* to inspect its state. Like I said earlier, I think pushurl has a very limited usecase: when the two URLs are actually mirrors (there is really no fork; we're back in a centralized environment). In fact, I think it should be deprecated, because it interferes with my more general approach. Let's see what happens if we have two actual remotes. remote/refs/origin/* will be updated when I fetch from, and push to, origin. remote/refs/ram/* will be updated when I fetch from, and push to, ram. It's very simple, and I don't need this complex rule of when to update refs. We should have a way to pair remotes together as upstream/ downstream in the future. Maybe even have a hierarchy of remotes. -- 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