Re: [ITCH] Specify refspec without remote

From: Jeff King <peff@peff.net>
Date: Apr 10, 2013, 20:21 UTC
Message-ID: <20130410202105.GE24177@sigill.intra.peff.net>
In-Reply-To: <CALkWK0nAMVKuDg4wmwujkpNxAF9zxQEdsZXyUzr+w4zVpWDCzA@mail.gmail.com>

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

Show 23 quoted lines

> 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?

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).

Show 6 quoted lines

> > As I said in an
> > earlier message, I would be OK with allowing both or neither, but
> > allowing one but not the other is even more confusing.
> 
> What is the point of allowing something internally consistent, but
> nonsensical?  You should complain.

If I were designing it today, I definitely think complaining is the right thing to do. My only hesitation is the backwards compatibility.

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.

-Peff