Re: [ITCH] Specify refspec without remote

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 12, 2013, 22:14 UTC
Message-ID: <7v4nfbcs6h.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130410185958.GA22394@sigill.intra.peff.net>

Jeff King <peff@peff.net> 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.