git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Brian Malehorn <bmalehorn@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] interpret-trailers: obey scissors lines
Date: Mon, 15 May 2017 11:12:03 +0900	[thread overview]
Message-ID: <xmqqfug6yiks.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170514035652.rn5npxxflku6s5k4@sigill.intra.peff.net> (Jeff King's message of "Sat, 13 May 2017 23:56:53 -0400")

Jeff King <peff@peff.net> writes:

>> If a commit message is being editted as "verbose", it will contain a
>> scissors string ("-- >8 --") and a diff:
>> 
>>     my subject
>> 
>>     # ------------------------ >8 ------------------------
>>     # Do not touch the line above.
>>     # Everything below will be removed.
>>     diff --git a/foo.txt b/foo.txt
>>     index 5716ca5..7601807 100644
>>     --- a/foo.txt
>>     +++ b/foo.txt
>>     @@ -1 +1 @@
>>     -bar
>>     +baz
>> 
>> interpret-trailers doesn't interpret the scissors and therefore places
>> trailer information after the diff. A simple reproduction is:
>> 
>>     git config commit.verbose true
>>     GIT_EDITOR='git interpret-trailers --in-place --trailer Acked-by:me' \
>>         git commit --amend

So, "git commit --amend --verbose" prepares something like the above
example and passes it to the GIT_EDITOR.  The problem description
indicates that because interpret-trailers (which happens to be used
as the GIT_EDITOR) treats the cut-line used by "git commit" just
like any other random line, it tries to find the trailer block way
below, in the patch text.  I agree that it is a problem.  But...

>> diff --git a/builtin/commit.c b/builtin/commit.c
>> index 2de5f6cc6..2ce9c339d 100644
>> --- a/builtin/commit.c
>> +++ b/builtin/commit.c
>> @@ -1735,7 +1735,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>>  
>>  	if (verbose || /* Truncate the message just before the diff, if any. */
>>  	    cleanup_mode == CLEANUP_SCISSORS)
>> -		wt_status_truncate_message_at_cut_line(&sb);
>> +		strbuf_setlen(&sb,
>> +			      wt_status_last_nonscissors_index(sb.buf, sb.len));
>
> This hunk surprised me at first (that we would need to touch commit.c at
> all), but the refactoring makes sense.

This still surprises me.  If the problem is in interpret-trailers,
why do we even need to touch cmd_commit()?  If GIT_EDITOR returns us

     my subject
 
     Acked-by: me
     # ------------------------ >8 ------------------------
     # Do not touch the line above.
     # Everything below will be removed.
     diff --git a/foo.txt b/foo.txt
     index 5716ca5..7601807 100644
     --- a/foo.txt
     +++ b/foo.txt
     @@ -1 +1 @@
     -bar
     +baz

after this patch fixes interpret-trailers, wouldn't the cmd_commit()
function work as expected without any change?

Puzzled.

The proposed log message calls the cut-line "scissors", but that is
probably a source of this confusion.  The cut-line and scissors do
not have much in commmon.  For one thing, scissors is a mechanism to
discard everything _ABOVE_ it.  The cut-line we see in this example,
on the other hand, is about discarding everything _BELOW_ it.

  parent reply	other threads:[~2017-05-15  2:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12  5:03 [PATCH 0/3] interpret-trailers + commit -v bugfix Brian Malehorn
2017-05-12  5:03 ` [PATCH 1/3] mailinfo.c: is_scissors_line ends on newline Brian Malehorn
2017-05-12  8:31   ` Jeff King
2017-05-12  5:03 ` [PATCH 2/3] commit.c: add is_scissors_line Brian Malehorn
2017-05-12  8:40   ` Jeff King
2017-05-12  5:03 ` [PATCH 3/3] commit.c: skip scissors when computing trailers Brian Malehorn
2017-05-12  8:52   ` Jeff King
2017-05-12  9:00 ` [PATCH 0/3] interpret-trailers + commit -v bugfix Jeff King
2017-05-14  3:39   ` Brian Malehorn
2017-05-14  3:39     ` [PATCH] interpret-trailers: obey scissors lines Brian Malehorn
2017-05-14  3:56       ` Jeff King
2017-05-14  8:33         ` Brian Malehorn
2017-05-14  8:33           ` Brian Malehorn
2017-05-15  3:55             ` Junio C Hamano
2017-05-15  4:23               ` Junio C Hamano
2017-05-16  6:06                 ` Brian Malehorn
2017-05-16  6:06                   ` [PATCH] interpret-trailers: honor the cut line Brian Malehorn
2017-05-16  6:42                   ` [PATCH] interpret-trailers: obey scissors lines Junio C Hamano
2017-05-15  3:08           ` Jeff King
2017-05-15  2:12         ` Junio C Hamano [this message]
2017-05-15  3:07           ` Jeff King
2017-05-15  3:32             ` Junio C Hamano
2017-05-15  3:33               ` Jeff King
2017-05-14  7:02       ` Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqfug6yiks.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=bmalehorn@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).