On Sat, Sep 23, 2023 at 10:47:29AM -0400, Theodore Ts'o wrote:
On Sat, Sep 23, 2023 at 05:41:19PM +0800, Stephen Zhang wrote:
Apologies for this confusion. It appears that the '--subject-prefix' option of the 'git send-email' command does not work with the local patch file.
Stephen,
The --subject-prefix option applies to "git format-patch" when the local patch file is generated, as opposed to "git send-email". So my general workflow is to run "rm -rf /tmp/p ; git format-patch -o /tmp/p ..." and then examine the files in /tmp/p, and then if they look good, run "git send-email /tmp/p/*".
I suspect it will be easier for Greg if you were to simply regenerate the patches with the proper subject prefix, and then resend them, since he has automation tools that can handle parsing the subject line, which scripts can do much more easily than to disentangling the "In-Reply-To" header to identify e-mail chains, and then parsing human/natural language to figure out which git tree the patches should be applied to. :-)
Just a hint, I can usually NOT see the In-Reply-To headers at all, as the email it was in response to is long gone from my system.
Which is why, the description of how to fix up a patch for the stable tree that has failed to apply there, tells you how to do this in a way that will show the proper version number.
If only anyone would actually read the emails we sent with the helpful text, here's one example for a DRM patch that failed to apply:
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x ec5fa9fcdeca69edf7dab5ca3b2e0ceb1c08fe9a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to 'stable@vger.kernel.org' --in-reply-to '2023092029-banter-truth-cf72@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
thanks,
greg k-h