Re: [PATCH 2/2] rebase -i: new option --name-rev

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

Dominique Quatravaux <domq@google.com> writes:

> On Thu, Mar 8, 2012 at 11:56 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
>> On a general note: you are submitting a completely new feature touching
>> a heavily-used tool (and code path) during -rc0 time. As a rule of
>> thumb: Don't do that. If you do it, don't Cc Junio unless it's his area
>> of code.
>
> [- gitster]
> Sorry about that, I skimmed Junio's "What's cooking in git.git (Mar
> 2012, #03; Mon, 5)" and I thought I was in the "high value/damage
> ratio" category.

Well, these days, nothing that comes without prior discussion on
pain points before the feature freeze, be it from seasoned list
regulars or from people new to this list, can be of so high-value
that it cannot wait until the next cycle.

The only handful of exceptions I can think of are:

 (1) an obvious fix to a high-risk bug (new or old) that was
     recently discovered as a potential attack vector;

 (2) an obvious fix to a bug in a new feature added in the upcoming
     release; or

 (3) an obviously necessary tweak and adjustment to parts of the
     system related to a new feature added in the upcoming release.

(1) is called "security fix" and (2) is "brown paper bag fix".

I do not think of a good word to explain (3), but for example, if a
release candidate added a feature to "git merge" so that a signed
tag can be merged while recording the signature in the resulting
commit, but the feature did not trigger when the merge is made via
"git pull" because it unwrapped the fetched tag to a commit before
calling "git merge", an update to "git pull" and probably "git
fmt-merge-msg" that is used by "git pull" may have to be made after
we enter the soft feature freeze (-rc0) for the new feature in "git
merge" to be useful.