On 03/09/2012 07:30 PM, Marc Branchaud wrote: > On 12-03-09 05:25 AM, Carlos Martín Nieto wrote: >> On Fri, 2012-03-09 at 09:31 +0100, Matthieu Moy wrote: >>> This patch prepares a transition to 'upstream', unlike the previous >>> version which was advertizing 'current'. In most case, this would be >>> the same, but 'upstream' is probably more sensible in case it points >>> to a branch other than 'current'. I don't care much either way. >>> >> >> For people using git as VCS that happens to have local history rather >> than taking full advantage of the distributed nature (or who aren't >> aware of it or don't get it), 'matching' is bound to be confusing. >> However, IMO 'current' makes more sense. Consider >> [...] > > I disagree and consider "upstream" to be the more reasonable default. > [...] I think that either "current" or "upstream" would be an improvement on the current behavior, but each of them is inappropriate in certain workflows (even among centralized workflows). 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. Of course, users who have a strong preference for what is the "right thing" in the ambiguous case can fine-tune their local preference to "current" or "upstream"; this would amount to a relaxation of the strict default policy. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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