Ingo Molnar <mingo@xxxxxxx> writes:
> (moved from lkml to the Git list)
>
> * Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
>> > Mailer:
>> > git-send-email 1.6.5.2
>>
>> Please teach your git-send-email thing to use --no-chain-reply-to.
> ...
> So ... the question would be ... could git-send-email flip its default
> please, via the patch below? Am i missing something subtle about why
> this default was chosen?
I do not think there was any conscious decision made when the
chain-reply-to was added. It was done and it got stuck.
I think the _only_ argument anybody _could_ make (and I won't be making
it, as I'd rather wish we had no-chain-reply-to the default from day one)
against the change of default is that it is a change [*1*].
Lkml already had two rather heated discussion in the past,
After the first round, I said we'd change the default to no-chain-reply-to
in release 1.6.3 unless somebody makes a convincing argument why the
default should not change, back around the time we were preparing for
1.6.2 (February 2009).
http://thread.gmane.org/gmane.comp.version-control.git/109790
Nobody complained.
Then I forgot to make such a declaration in the release notes to 1.6.3,
and no such declaration appeard in later release notes, either.
But nobody complained (nor reminded me).
The second round of the discussion was in August 2009. This time I did
something to prevent me from forgetting in the future.
http://thread.gmane.org/gmane.linux.kernel/879975/focus=880938
This patch is queued in 'next', scheduled to graduate to 'master' for the
1.7.0 release.
[Footnote]
*1* To spell it out... The people who are in the "hate chain-reply-to
very much" camp would have already done their own configuration to get the
behaviour they want by now, so changing the default would not help them
much, while potentially hurting "love chain-reply-to" people who have been
content because they got what they wanted without setting any
configuration.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html