Jeff King <peff@xxxxxxxx> writes:
> Which is still kind of weird, because why should the branch you are on
> affect the default push location? But that is how default "matching" has
> always behaved, and we would remain consistent with that.
I agree that what makes us behave "kind of weird" is that the
current branch is used to look up branch.$name.{remote,pushremote}
when pushing. I do not think "matching" [*1*] has anything to do
with it.
The per-branch configuration, branch.$name.{remote,pushremote}, says
"this branch interacts with a remote that is different from what I
normally interact with".
It is excusable for branch.$name.remote to take the current branch
into account, when it is used to govern the fetch-integrate side
(i.e. not used as a fall-back for branch.$name.pushremote). In
order to affect that configured local branch, e.g. "git pull" to
merge other's work, you need to have that named branch checked out
in your working tree. Triggering the effect of the configuration
based on which branch is checked out makes more sense because of
that reason when you are fetching.
It does not make much sense to use the current branch as the key to
look it up when you are pushing things out. If anything, what is
being pushed out should be what determines where it goes.
But that is a realization that comes after you think the issue long
and hard enough. To a casual end user, I think it is an equally or
even more natural expectation a "git push" would pick the destination
based on what branch you are currently on, as that is what happens
when he runs the command without any argument.
[Footnote]
*1* The "matching" semantics is to support the workflow for people
who batch things up. You perfect _all_ your branches that matter to
the public, and push all of them in one go. If you do not finish a
work on one branch and push out when other branches are not yet
ready, you do not want your push to be limited to the current
branch. And you do not have to "configure" what branches should be
visible to the public. Instead, you have _your_ remote remember it
for you: what are already there are the ones that are updated.
The "current", "upstream", etc. are to support folks who want to
push work done on a single branch out as soon as it is done, even
though the other branches are in no shape to be pushed out.
--
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