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