| Message ID | 20210824114135.54810-1-carenas@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] send-email: allow fixing the cover letter subject | expand |
On 24/08/2021 13:41, Carlo Marcelo Arenas Belón wrote: > @@ -1719,7 +1719,6 @@ sub process_file { > @xh = (); > my $input_format = undef; > my @header = (); > - $subject = $initial_subject; This change from my patch is still controversial, and I'd rather not submit the addition if it's immediately removed again. Why are you dropping it here anyway, does it break any related functionality? Best regards, Marvin
On Tue, Aug 24, 2021 at 8:19 AM Marvin Häuser <mhaeuser@posteo.de> wrote: > On 24/08/2021 13:41, Carlo Marcelo Arenas Belón wrote: > > @@ -1719,7 +1719,6 @@ sub process_file { > > @xh = (); > > my $input_format = undef; > > my @header = (); > > - $subject = $initial_subject; > > This change from my patch is still controversial, and I'd rather not > submit the addition if it's immediately removed again. > Why are you dropping it here anyway, does it break any related > functionality? I was expecting it to break --compose, but it didn't because in there we were using $initial_subject directly instead. AFAIK; I couldn't see a difference eitherway, but as Peff pointed out it doesn't make sense leaving it only as a global so just found instead a more useful place for it to be reset in the loop, which also "fix" another issue of mine. As pointed out in my original email; it doesn't fix the whole problem though, because you still want to edit the rest of the cover letter (could use --annotate for that though), but at least it is less awkward than the current situation, where you will get the series submission aborted because of an incorrect subject, even if a correct one was provided and ended up being ignored. Carlo Carlo
On 24/08/2021 18:11, Carlo Arenas wrote: > On Tue, Aug 24, 2021 at 8:19 AM Marvin Häuser <mhaeuser@posteo.de> wrote: >> On 24/08/2021 13:41, Carlo Marcelo Arenas Belón wrote: >>> @@ -1719,7 +1719,6 @@ sub process_file { >>> @xh = (); >>> my $input_format = undef; >>> my @header = (); >>> - $subject = $initial_subject; >> This change from my patch is still controversial, and I'd rather not >> submit the addition if it's immediately removed again. >> Why are you dropping it here anyway, does it break any related >> functionality? > I was expecting it to break --compose, but it didn't because in there > we were using $initial_subject directly instead. Right, ok. > AFAIK; I couldn't see a difference eitherway, but as Peff pointed out > it doesn't make sense leaving it only as a global so just found > instead a more useful place for it to be reset in the loop, which also > "fix" another issue of mine. Well, this only "sometimes" resets it (from a control flow perspective), which is exactly what I tried to avoid globally. Can we somehow agree on something? Because I'd like to submit my patch asap. Best regards, Marvin
On Tue, Aug 24, 2021 at 11:31 PM Marvin Häuser <mhaeuser@posteo.de> wrote: > On 24/08/2021 18:11, Carlo Arenas wrote: > > On Tue, Aug 24, 2021 at 8:19 AM Marvin Häuser <mhaeuser@posteo.de> wrote: > >> On 24/08/2021 13:41, Carlo Marcelo Arenas Belón wrote: > >>> @@ -1719,7 +1719,6 @@ sub process_file { > >>> @xh = (); > >>> my $input_format = undef; > >>> my @header = (); > >>> - $subject = $initial_subject; > Can we somehow agree on something? Because I'd like to submit my patch asap. I think you are correct, and from a flow point of view it should be reset there with the rest. Adding something to the commit message to explain it might help, and the documentation path I suggested (or something better) might be worth squashing to better explain why the last test case that resets in-reply-to headers is correct. Carlo
On 26/08/2021 12:58, Carlo Arenas wrote: > I think you are correct, and from a flow point of view it should be > reset there with the rest. > Adding something to the commit message to explain it might help, and > the documentation path > I suggested (or something better) might be worth squashing to better > explain why the last test case that resets in-reply-to headers is > correct. Squashing, you mean from your patch into mine? If that is what you mean, can you maybe do that and add SOB Peff for the other tests? It could just be one patch set really. If that is not what you mean, I will submit our (Peff's and my changes) patch as-is tomorrow. Best regards, Marvin > > Carlo
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 3db4eab4ba..9d2bfa6095 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -113,8 +113,7 @@ is not set, this will be prompted for. --subject=<string>:: Specify the initial subject of the email thread. - Only necessary if --compose is also set. If --compose - is not set, this will be prompted for. + Only necessary if --compose or --cover-letter are also set. --to=<address>,...:: Specify the primary recipient of the emails generated. Generally, this diff --git a/git-send-email.perl b/git-send-email.perl index fd79849530..a33328a5d9 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -997,7 +997,7 @@ sub file_declares_8bit_cte { default => "UTF-8"); } -if (!$force) { +if (!$force and not defined $initial_subject) { for my $f (@files) { if (get_patch_subject($f) =~ /\Q*** SUBJECT HERE ***\E/) { die sprintf(__("Refusing to send because the patch\n\t%s\n" @@ -1719,7 +1719,6 @@ sub process_file { @xh = (); my $input_format = undef; my @header = (); - $subject = $initial_subject; $message = ""; $message_num++; # First unfold multiline header fields @@ -1747,6 +1746,11 @@ sub process_file { if (defined $input_format && $input_format eq 'mbox') { if (/^Subject:\s+(.*)$/i) { $subject = $1; + + if (defined $initial_subject && + $subject =~ /\Q*** SUBJECT HERE ***\E/) { + $subject = $initial_subject; + } } elsif (/^From:\s+(.*)$/i) { ($author, $author_encoding) = unquote_rfc2047($1); diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh index 747872d5be..043532fe85 100755 --- a/t/t9001-send-email.sh +++ b/t/t9001-send-email.sh @@ -1728,7 +1728,6 @@ test_expect_success $PREREQ 'CRLF and sendemail.transferencoding=base64' ' test_cmp expected actual ' - # Note that the patches in this test are deliberately out of order; we # want to make sure it works even if the cover-letter is not in the # first mail. @@ -1765,6 +1764,21 @@ test_expect_success $PREREQ '--force sends cover letter template anyway' ' test -n "$(ls msgtxt*)" ' +test_expect_success $PREREQ '--subject can be used to fix the cover letter' ' + clean_fake_sendmail && + git send-email \ + --cover-letter -2 \ + --subject="foo" \ + --from="Example <nobody@example.com>" \ + --to=nobody@example.com \ + --smtp-server="$(pwd)/fake.sendmail" \ + 2>errors >out && + ! grep "SUBJECT HERE" errors && + ls msgtxt* >list && + test_line_count = 3 list && + grep "Subject: foo" msgtxt1 +' + test_cover_addresses () { header="$1" shift
a03bc5b6ad (send-email: Refuse to send cover-letter template subject, 2009-06-08) fixes a common problem with the direct use of `git send-email` to send topics, where the cover letter will be a template by accident. Allow using --subject to fix the --cover-letter subject and skip the safety check without having to use --force. Note that the use of --compose is also allowed, and will also get its Subject set through the commandline, but it might make more sense to instead make them incompatible and force editing the cover letter instead, hence why sending this only as a RFC. patch is based on another one[1] still in fly, and the documentation change is long overdue, but probably should need a better explanation; lastly using a non ASCII subject also needs fixing, but it also affects compose, so was left out for now. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> [1] https://lore.kernel.org/git/4db7759c-2123-533b-9f89-954c07f5832a@posteo.de/ --- Documentation/git-send-email.txt | 3 +-- git-send-email.perl | 8 ++++++-- t/t9001-send-email.sh | 16 +++++++++++++++- 3 files changed, 22 insertions(+), 5 deletions(-)