On 2 April 2012 23:16, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > demerphq <demerphq@xxxxxxxxx> writes: > >> And actually I find your use of "git pull" and "pull" in the >> expression "pull from a branch other than one with the same name" >> confusing. Barring misconfiguration pull operates on only one local >> branch and it is usually the one with the same name. However push >> operates on multiple local branches. > > It does with push.default = matching, but with either options we are > discussing here, argumentless "git push" would push only one branch. > The choice we have is whether to push to the branch with the same name, > or to the branch from which "git pull" would take the changes. Ah, then I misunderstood your point. Probably because of the point you make next. > (I realize that in this discussion, "current" may be misleading. I mean > "push.default=current", not "the behavior we have currently") > >> Lastly I have never really encountered any confusion with explaining >> the default behaviour of git-fetch, nor actually git-pull, but I have >> encountered lots of confusion of people using git-push. They expect >> git-push to be the opposite of git-pull not git-fetch. > > I do also expect "git pull" to be symmetrical to "git pull", and > "push.default=upstream" is the closest to symmetry. After clarifying what he meant off-list I'd just like to say that I agree with Matthieu. Picking a default that makes git-push not be the opposite of git-pull will end up surprising some people some of the time. Enough that I suspect that this conversation will be coming up again in the future. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- 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