Re: [ITCH] Specify refspec without remote

Jeff King wrote:

On Thu, Apr 11, 2013 at 01:35:34AM +0530, Ramkumar Ramachandra wrote:

quoted

Jeff King wrote:

quoted

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.