Re: [ITCH] Specify refspec without remote

[Ramkumar Ramachandra <artagnon@gmail.com>]

Jeff King wrote:
> On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote:
>
>> Jeff King wrote:
>> > Maybe. But no more so than the current:
>> >
>> >   git push
>> >
>> > which may also push master and next to the same remote.
>>
>> I would argue that this was not really a problem in practice, until I
>> introduced branch.<name>.pushremote.
>>
>> Let us imagine that I was working on artagnon/git.git (remote: ram), a
>> fork of git/git.git (remote: origin) earlier.  My fork contains the
>> link and implicit-push branches in addition to the master, next and pu
>> branches, which are present on both.  When I push from my
>> implicit-push branch with push.default = matching, I'm updating all
>> the matching refs on the remote ram (since branch.implicit-push.remote
>> is set to ram), which is fine.  Now, I git push while on branch
>> master.  My push is simply rejected, as I don't have write access to
>> the remote origin.
>>
>> This is designed exactly for the read-only upstream, read-write fork
>> scenario.  If I had write access to upstream (where we're essentially
>> regression to a centralized model), we'd have some major confusion.
>
> I don't see how pushremote changes that. It was already a problem with
> branch.*.remote, no?

Technically, it changes nothing.  pushremote is only an enabler for
more complex scenarios where git push; breaking user expectations is
magnified.

According to me, what branch.<name>.pushremote suddenly starts
supporting (apart from the use I intended for it) is each branch
having different read/ write access.  So, we're back to git.git where
Junio has graciously given me write support to pu, but not next or
master.  So I set up branch.master.pushremote and
branch.next.pushremote to ram and run git push; from pu.  Disaster:
the pu ref went through fine, but master and next failed to get pushed
despite me specifying a proper pushremote for them.

> I have a similar remote setup in my git.git repository. But all of my
> branch.*.remote variables point to origin, because my branches are based
> off of Junio's master. A matching push goes to the wrong place (and I
> have screwed it up many times; it is nice that I do not have write
> access to Junio's repository). The is broken without having pushremote
> at all (and the proper fix is your remote.pushdefault).

Yeah, I can't believe I lived without remote.pushdefault for this long.

> If we are not going to break the existing behavior, I think it can be
> argued that consistency and simplicity of the rules is important, so the
> user can predict what will happen. But the more we discuss, the more I
> think we should simply change the current behavior (to stop respecting
> branch.* config with "matching"), which just seems wrong to me. Then we
> can be simple and consistent, and do what the user probably intended.

So there are some push.default options that respect branch.* config
(ie. "current"), and others that don't (ie. "matching").  I would
argue that push.default is badly designed to begin with, so the
solution makes sense to me even if the patch is a bit of hack; we
never guaranteed that the various push.default options respect the
same configuration variables.