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@xxxxxxxxxxxxxxx>' --in-reply-to '2023092029-banter-truth-cf72@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. thanks, greg k-h
