On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:
> This has been annoying me for a really long time, but I never really
> got around to scratching this particular itch. I have a very common
> scenario where I fork a project on GitHub. I have two configured
> remotes: origin which points to "git://upstream" and mine which points
> to "ssh://mine". By default, I always want to pull `master` from
> origin and push to mine.
Same here. Even without GitHub, working on git.git I treat Junio as my
"origin", but push to a publishing point.
> Unfortunately, there's only a branch.<name>.remote which specifies
> which remote to use for both pulling and pushing. There's also a
> remote.<name>.pushurl, but I get the feeling that this exists for an
> entirely different reason: when I have a server with a
> highly-available read-only mirror of the repository at
> git://anongit.*, and a less-available committer-only mirror at
> ssh://*.
Yeah, you don't want to use pushurl. It makes the assumption that you
are pushing to the same remote, so when you, e.g., push to the remote's
refs/heads/master, it will update refs/remotes/origin/master. But that's
not right; that ref should be tracking the true origin, not what you
pushed to.
> How about a branch.<name>.remotepush that specifies a special remote
> for pushing, falling back to branch.<name>.remote?
Sure, though I wonder if you really want a per-branch config, or if you
just want remote.pushDefault or similar, so that you do not have to
configure each branch independently as you create it. I'm imagining
lookup rules something like:
1. If we are on branch $b, check branch.$b.pushRemote.
2. If not set, check remote.pushDefault.
3. If not set, check branch.$b.remote.
4. If not set, check remote.default (there was a proposal for this a
few months ago, but it got stalled).
5. If not set, use "origin".
And then fetching could do the same, with s/push/fetch/. In both cases,
if you are not using the new variables, the behavior is the same as
the current behavior.
-Peff
--
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