Ingo Molnar [off-list ref] writes:
(moved from lkml to the Git list)
* Peter Zijlstra [off-list ref] wrote:
quoted
quoted
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.
* Junio C Hamano [off-list ref] wrote:
[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.
Stupid question: i researched the Git mailing list archive (and read the
link you provided) and found no arguments (at all) in favor of the
nested chaining. Are you aware of any?
And i dont 'hate' it - i am just the one suffering from it as a
maintainer. _I_ can certainly fix my scripts as you suggest above, but
that is not my problem: my problem are the many people sending
first-time Git based patch series to me (and there's quite a few of
them) always, in every single case, get it wrong.
The ones not using Git (using Quilt for example) and sending me series
get it right in pretty much every case.
So i can see it when developers start using Git to submit patches - in
each and every case - the discussion threading is all messed up ;-)
These people dont 'do their own configuration' - they are mostly newbies
or developrs new to Git workflows. And the first reaction they get from
their upstream maintainer counterpart is some grumbling about the
threading. Not good, me thinks ;-)
Ingo
* Ingo Molnar [off-list ref] wrote:
* Junio C Hamano [off-list ref] wrote:
quoted
[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.
Stupid question: i researched the Git mailing list archive (and read
the link you provided) and found no arguments (at all) in favor of the
nested chaining. Are you aware of any?
Btw., dont get me wrong - i'm perfectly happy with the fix in 1.7.0. You
are also right that behavioral changes dont belong into stable releases.
( I'm just seeing this problem through the biased eyes of someone who is
affected by it, so i naturally want to have the benefit of the change
ASAP - without fully perceiving the risks of the change.)
Thanks,
Ingo