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