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

[Andreas Ericsson <ae@op5.se>]

Steffen Prohaska wrote:
> 
> 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.
> 

I'd really, really hate that. I often have changes on several branches
when I push. I like the behaviour as it is today.

> 
>> 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.
> 

Ugh. People who neither know nor care about git development will
wonder why the hell they now have to tell git something in order
for it to do something it's always done anyway. The majority of
git users never read release-notes. They just do "yum update" and
then go about their business the same way they've always done.

Newcomers that obviously have no such configuration will wonder
why they're getting warnings from using the standard command-set.

> ...
> 
>> 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 ;)
> 

If the default's to be changed, making it default to no-op is really
the only sensible thing to do. Otherwise I'm guessing a lot of people
that actually count on the current behaviour will get quite vexed, and
--current is definitely not the universally correct default thing to do.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231