On 10/21/2015 08:39 AM, Peter Zijlstra wrote:
Can you *please* start a new thread with each posting?
This is absolutely unmanageable.
I've been explicitly threading the multiple patch series on purpose
due to this text in "git help send-email":
--in-reply-to=<identifier>
Make the first mail (or all the mails with --no-thread) appear
as a reply to the given Message-Id, which avoids breaking
threads to provide a new patch series. The second and subsequent
emails will be sent as replies according to the
--[no]-chain-reply-to setting.
So for example when --thread and --no-chain-reply-to are
specified, the second and subsequent patches will be replies to
the first one like in the illustration below where [PATCH v2
0/3] is in reply to [PATCH 0/2]:
[PATCH 0/2] Here is what I did...
[PATCH 1/2] Clean up and tests
[PATCH 2/2] Implementation
[PATCH v2 0/3] Here is a reroll
[PATCH v2 1/3] Clean up
[PATCH v2 2/3] New tests
[PATCH v2 3/3] Implementation
It sounds like this is exactly the behavior you are objecting
to. It's all one to me because I am not seeing these emails
come up in some hugely nested fashion, but just viewing the
responses that I haven't yet triaged away.
So is your recommendation to avoid the git send-email --in-reply-to
option? If so, would you recommend including an lkml.kernel.org
link in the cover letter pointing to the previous version, or
is there something else that would make your workflow better?
If you think this is actually the wrong thing, is it worth trying
to fix the git docs to deprecate this option? Or is it more a question
of scale, and the 80-odd patches that I've posted so far just pushed
an otherwise good system into a more dysfunctional mode? If so,
perhaps some text in Documentation/SubmittingPatches would be
helpful here.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
