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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html