Re: [RFC PATCH] push: start warning upcoming default change for push.default

[Michael Haggerty <mhagger@alum.mit.edu>]

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@alum.mit.edu
http://softwareswirl.blogspot.com/