Re: What's cooking in git.git (Aug 2008, #03; Thu, 14)

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Thu, 14 Aug 2008, Junio C Hamano wrote:
>
>> * js/checkout-dwim-local (Sat Aug 9 16:00:12 2008 +0200) 1 commit
>>  + checkout --track: make up a sensible branch name if '-b' was
>>    omitted
>> 
>> I like this low-impact usability enhancement; will most likely be in
>> master soon after 1.6.0.
>
> Pity.  I kinda hoped it would make it into 1.6.0.

I do not see any pity here.  I do not think this is so high-impact that
needs to wait major version boundary --- it can go to 1.6.1 without
waiting for 1.7.0.

The policy of not taking new features and unproven "fixes" after -rc1 is
threefold.

 (1) We would want to avoid regression caused by last minute carelessness
     (e.g. a "fix" that wants to cover one user mistake and give an
     "appropriate" error message would give a wrong error message if it
     inadvertently covered cases wider than it should have).  

 (2) We would want to have enough time to advertize the change in advance
     if the change can introduce backward incompatibilities.

 (3) We would want to make sure that the change is general enough without
     obvious room for improvement (we do not want to give half-baked
     feature, soon to get replaced by something else).

But taking this before 1.6.0 would be a pity. I do not offhand think the
change can have downside impact (it is _supposed to_ kick in only when it
would have been an error earlier), so it may be excempt from #2 of the
post -rc rules, but I do think you and I have a track record of being
careless (not because your patches are often bad, but because you and I
tend to make the same kind of mistakes --- overlooking the same kind of
cases where changes are not such a good idea.  Notice I said "offhand" a
few lines earlier?), and I feel it is prudent to let rule #1 and #3 to
hold us back a bit longer.