[OE-core] [PATCH V2] scripts.send-pull-request: Avoid multiple chain headers

[Patrick Ohly]

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 <jose.a.lamego at linux.intel.com>
> ---
>  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.