Jeff King [off-list ref] writes:
On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:
quoted
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.
The "you fetch from and push to the same place" semantics that
associates a branch to a single remote was primarily done for people
coming from CVS/SVN background [*1*]. I think the triangle
arrangement where you want to have "this is where I fetch from and
integrate with, and that is where I publish" is more common among
the Git users these days.
How best to express the triangle is somewhat tricky, but I think it
is sensible to say you have "origin" that points to your upstream
(i.e. me), and "peff" that points to your publishing point, in other
words, make it explicit that the user deals with two remotes. Then
have push.default name the remote "peff", so that "git push" goes to
that remote by default (and have "git fetch/pull" go to "origin).
You will have two sets of remote tracking branches (one from "origin"
that your push will never pretend to have fetched immediately after
finishing, the other from "peff" that keeps track of what you pushed
the last time).
Of course, some people may have "I use this and that branches to
interact with upstream X while I use these other branches to
interacct with upstream Y, and all of them push to different
places", and supporting that may need complex per branch "On this
branch fetch from and integrate with remote X, and push to remote Z"
settings, but as you said, "I fetch from and integrate with X, and
result is pushed out to Y" should be the most common, and it would
be desirable to have a simple way to express it with just a single
new configuration variable.
[Footnote]
*1* It also happens to work reasonably well for people like Linus
and I with the "I pull from random places, I locally integrate and I
publish the results" workflow, because we are trained to think that
it is not just being lazy but simply meaningless to say "git pull"
without saying "fetch and integrate _what_ and from _whom_", and
that is only because we do not have a fixed upstream. Linus and I
would practically never fetch from "origin", i.e. from ourselves.
On Thu, Feb 07, 2013 at 10:08:48PM -0800, Junio C Hamano wrote:
How best to express the triangle is somewhat tricky, but I think it
is sensible to say you have "origin" that points to your upstream
(i.e. me), and "peff" that points to your publishing point, in other
words, make it explicit that the user deals with two remotes. Then
have push.default name the remote "peff", so that "git push" goes to
that remote by default (and have "git fetch/pull" go to "origin).
You will have two sets of remote tracking branches (one from "origin"
that your push will never pretend to have fetched immediately after
finishing, the other from "peff" that keeps track of what you pushed
the last time).
Exactly. That is what I have set up now, except that I have to type "git
push peff" because there is no such push.default (with the minor nit
that push.default does something else, so the config should be called
remote.pushDefault or something). The entirety of the feature would be
saving the user from the annoyance of:
$ git push
fatal: remote error:
You can't push to git://github.com/gitster/git.git
Use git@github.com:gitster/git.git
[doh! Stupid git, why don't you do what I mean, not what I say?]
$ git push peff
... it works ...
Of course, some people may have "I use this and that branches to
interact with upstream X while I use these other branches to
interacct with upstream Y, and all of them push to different
places", and supporting that may need complex per branch "On this
branch fetch from and integrate with remote X, and push to remote Z"
settings, but as you said, "I fetch from and integrate with X, and
result is pushed out to Y" should be the most common, and it would
be desirable to have a simple way to express it with just a single
new configuration variable.
Right. Frankly, I do not care that much about the per-branch push remote
myself. In the rules I gave earlier, that was my complete
backwards-compatible vision, so that we do not paint ourselves into a
corner compatibility-wise when somebody wants it later. Just
implementing the default push remote part would be a fine first step.
I also indicated in my rules that we could have a branch.*.fetchRemote,
as well, but I do not think it is strictly necessary. I think the
non-specific branch.*.remote could continue to be used for fetching, and
as a backup when the push-specific variables are not set.
*1* It also happens to work reasonably well for people like Linus
and I with the "I pull from random places, I locally integrate and I
publish the results" workflow, because we are trained to think that
it is not just being lazy but simply meaningless to say "git pull"
without saying "fetch and integrate _what_ and from _whom_", and
that is only because we do not have a fixed upstream. Linus and I
would practically never fetch from "origin", i.e. from ourselves.
Right, I think "git pull" is more useful in a centralized repo setting
where there is one branch and one repo, so there is no "what and whom"
to specify. Personally I do not use it much at all, as I do a separate
fetch, inspect, and merge, but that is somewhat orthogonal to your
reasons. :)
-Peff