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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2008, 03:29 UTC
Message-ID: <7vd4k8b9pb.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0808161731300.24820@pacific.mpi-cbg.de.mpi-cbg.de>

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

Show 10 quoted lines

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