Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > On 12-03-10 01:16 AM, Michael Haggerty wrote: >> >> I propose that the default should be even stricter: like "current", it >> would push to an branch with the same name as the current local branch, >> *but only if that branch already exists on the remote*. It would only >> be possible to create a new branch on the remote by calling "git push" >> with an explicit branch argument. I believe that such a policy would do >> the right thing in the cases where the "right thing" is pretty >> unambiguous, and would require a user decision in other cases. > > I haven't thought it through very deeply, but at first glance this seems like > reasonable default behaviour to me. I do find it reasonable, but I think 'upstream' has several advantages over it. * 'upstream' makes "git push" and "git pull" symmetrical. While there are workflows where it is usefull to have "push" and "pull" point to different branches, I think it is far more intuitive to have this symmetry by default. * For newbies, the sequence "create an empty repository, clone it, commit and push" works like a charm with either 'upstream' or 'current'. Today, the first push to an empty repository requires either saying "git push origin master" or "git push --all", both of which sound like black magic to the poor user who did not yet learn what 'origin' is and what a branch is. * 'upstream' makes it easy to create a local topic branch, and let 'push' send it to the master branch (i.e. have local 'topic-branch' pull and push to 'origin/master'). In general, 'upstream' allows workflows where you push to branches with either a different name or with the same name (by setting the upstream appropriately), but the opposite is not true. That being said, I think the mode you Michael described at least deserves to exist, even if I disagree that it would be the best default. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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