Re: [PATCH] send-email: do not insert third header

2014-06-10 Thread Stepan Kasal
On Mon, Jun 09, 2014 at 10:38:14PM -0700, Junio C Hamano wrote:
 two new options [..]
 would support the recent kernel submission convention better.

indeed, but they are not there and I do not volunteer to write them.

Instead, I edit the generated patches to add the necessary headers.
But if send-mail is used to mass-send these edited mails, it adds yet
another header.  As a quick solution, I fixed send-mail, so that it
respects the header added by hand.

Even if send-mail is in the future enhanced according to your
proposal, it is still possible that hand-crafted headers will be
needed for a special purpose, so my patch still may come handy.

Stepan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] send-email: do not insert third header

2014-06-09 Thread Junio C Hamano
Stepan Kasal ka...@ucw.cz writes:

 It is sometimes desirable to insert several header lines at the top of
 the body, e.g., if From or Date differs from the mail header.
 (Linus even recommends to use this second header for all kernel
 submissions.)

 send-email has a minimal support for this; make sure it is not applied
 when there is a second header already inserted in the patch file.

I have a slight suspicion that you are reading the recommendation
wrong.  We do not recommend to record these in-body headers in the
message of the commit object (the recommendation is to prepend
in-body headers to the message of the commit object when sending it
out for review---it pretty much assumes that the underlying commit
does not have these in-body headers that are used only during the
transit over e-mail forwarding chain).

But your patch seems to assume that the input message to send-email
already has the in-body header.  Doesn't that indicate a misuse of
the tool, making this new feature smell more like a way to
encourage such a misuse by covering up the result?

I dunno.


 Signed-off-by: Stepan Kasal ka...@ucw.cz
 ---
  git-send-email.perl | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/git-send-email.perl b/git-send-email.perl
 index 9949db0..891df13 100755
 --- a/git-send-email.perl
 +++ b/git-send-email.perl
 @@ -1456,7 +1456,9 @@ foreach my $t (@files) {
   }
  
   if (defined $sauthor and $sauthor ne $sender) {
 - $message = From: $author\n\n$message;
 + if ($message !~ m/^From: /) {
 + $message = From: $author\n\n$message;
 + }
   if (defined $author_encoding) {
   if ($has_content_type) {
   if ($body_encoding eq $author_encoding) {
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] send-email: do not insert third header

2014-06-09 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes:

 Stepan Kasal ka...@ucw.cz writes:

 It is sometimes desirable to insert several header lines at the top of
 the body, e.g., if From or Date differs from the mail header.
 (Linus even recommends to use this second header for all kernel
 submissions.)

 send-email has a minimal support for this; make sure it is not applied
 when there is a second header already inserted in the patch file.

 I have a slight suspicion that you are reading the recommendation
 wrong.  We do not recommend to record these in-body headers in the
 message of the commit object (the recommendation is to prepend
 in-body headers to the message of the commit object when sending it
 out for review---it pretty much assumes that the underlying commit
 does not have these in-body headers that are used only during the
 transit over e-mail forwarding chain).

 But your patch seems to assume that the input message to send-email
 already has the in-body header.  Doesn't that indicate a misuse of
 the tool, making this new feature smell more like a way to
 encourage such a misuse by covering up the result?

 I dunno.

I forgot to mention that possible enhancements. As you mentioned,
there is only a minimal support for this in send-email.  After you
committed somebody else's patch in your tree, format-patch will
produce the normal From: and Date: using the original author's
identity and timestamp, but send-email only uses the in-body header
for From: (but not Date:) to propagate this information and only
when the author is different from yourself.  It is plausible that
two new options to tell send-email to optionally

 (1) propagate Date: in the output from format-patch as an in-body
 header; and

 (2) propagate From: in the output from format-patch as an in-body
 header even when you are sending out your own patch

would support the recent kernel submission convention better.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html