Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch

> 
> On Nov 19, 2007, at 2:28 AM, Junio C Hamano wrote:
> 
> 
> 
>> I do not think it is "Often you want" that makes it awkward.
>>
>> Instead, the awkward case is if you do the "only the current"
>> push NOT often enough.  If it is often enough, you set the
>> configuration once and the awkwardness is behind you.
>>
>> If however it is not often enough, you cannot afford to have the
>> configuration above, because that would force you to tell from
>> the command line which branches, not just the current one, to
>> push, and that is inconvenient because it is not rare enough.
> 
> Will try to rephrase the commit message.
> 
> 
>> Together with your [PATCH 1/2], I like the general direction
>> these patckes are taking us, but it feels a bit too hasty.  I
>> personally am not convinced that switching to --current for
>> everybody is a good move.
>>
>>> ...
>>> Maybe in two years (that's twice an eternity in git time scales):
>>>
>>> 4) make "git push --current" the default.
>>
>> If these, both the uncertainly expressed by "Maybe" and "twice
>> an eternity" are true, which they are, the new warning in the
>> current patch are inappropriate.  Many people's settings depend
>> on a working "push the matching refs" behaviour, and we need a
>> very good excuse to annoy the existing happy users with such a
>> warning.
> 
> I think 3) is the interesting case.  "git push" should do
> nothing by default.  Either you can configure "git push" to do
> something by setting a remote.$remote.push line or you need
> to provide a command line switch.  But if you do not tell
> explicitly what you want, "git push" will not do anything
> for you.
> 

> 
>> Remember, how much vocal the dissenters might have been on the
>> list in the recent discussions, we need to consider the needs of
>> the silent majority that has been content with the current
>> behaviour for a long time.
>>
>> The "warning" to annoy them may be a way to get their attention
>> and get them involved in a discussion to decide what the default
>> should be.  But changing the default without giving the people
>> who do not like the _new_ default a way to avoid inconvenience
>> of always typing --matching or --current is not nice.  And
>> honestly, I do not think there is one single default that is
>> good for everybody.
> 
> Personally, I'd switch to the do-nothing default immediately.
> But you are right.  More work is needed to have a smooth transition.
> 
> 
>> We should be doing better.
>>
>> A smoother transition route would be:
>>
>>  - Keep "matching" the built-in default for now;
>>
>>  - Take your patches (but drop "warning" bits at this point) to
>>    introduce 'matching' and 'current' behaviours, and a way to
>>    override the built-in default from the command line;
>>
>>  - Introduce a configuration 'push.defaultRefs' ('matching' or
>>    'current') to override that built-in default, so people who
>>    prefer 'current' can override the built-in default, without
>>    having to type --current every time.
> 
> Sounds like a plan.
> 
> If we have the configuration variable, maybe we could switch
> off the default behaviour immediately.  Setting a single global
> config variable once would be sufficient to get it back.  So,
> we could change the default and print a recommendation to run
> 'git config --global push.defaultRefs matching' to get it back.
> 

> ...
> 
>> After all that happens, we can start discussing what the
>> built-in default should be.  When it is changed after the
>> discussion concludes (which may never happen), people who want
>> to keep 'matching' behaviour would have had the configuration
>> mechanism to override that built-in default for some time during
>> the discussion period.  So the beginning of that discussion
>> period is when we should start talking about "We might change
>> the default soon; set the configuration to your liking if you do
>> not want to get affected" in the warning.
> 
> ... And we'd not even start the discussion.  Because there's no
> need to.  Every user should make a choice, once.  We do not
> provide a default (which obviously will trigger another discussion ;)
>