On Mon, 2016-11-28 at 10:23 -0600, Jose Lamego wrote: > When creating a patch set with cover letter using the > send-pull-request script, both the "In-Reply-To" and "References" > headers are appended twice in patch 2 and subsequent.
The "why" part is missing in the commit header. "Why" is appending those twice a problem? Is it a bug in the script (because it violates some RFC) or is it merely a workaround for a problem in other software (mail programs or Patchwork)? I know that this change is related to the issues that Patchwork has with identifying a patch series, but even with that background knowledge it is not clear why this fix is the right solution. > This change appends only one header pointing to very first patch > in series or to cover letter if available. > > [YOCTO #10718] > > Signed-off-by: Jose Lamego <[email protected]> > --- > scripts/send-pull-request | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/send-pull-request b/scripts/send-pull-request > index 575549d..a660c37 100755 > --- a/scripts/send-pull-request > +++ b/scripts/send-pull-request > @@ -162,7 +162,7 @@ PATCHES=$(echo $PDIR/*.patch) > if [ $AUTO_CL -eq 1 ]; then > # Send the cover letter to every recipient, both specified as well as > # harvested. Then remove it from the patches list. > - eval "git send-email $GIT_TO $GIT_CC $GIT_EXTRA_CC --confirm=always > --no-chain-reply-to --suppress-cc=all $CL" > + eval "git send-email $GIT_TO $GIT_CC $GIT_EXTRA_CC --confirm=always > --no-thread --suppress-cc=all $CL" > if [ $? -eq 1 ]; then > echo "ERROR: failed to send cover-letter with automatic > recipients." > exit 1 And I don't understand why this proposed change has the described effect. Does changing the threading parameters change the output of "git send-email" and thus indirectly the mail headers of the following patches? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
