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 12:32:24 +0900	[thread overview]
Message-ID: <xmqqpofax0af.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170515030726.mmbb43zxqgtbrbuy@sigill.intra.peff.net> (Jeff King's message of "Sun, 14 May 2017 23:07:26 -0400")

Jeff King <peff@peff.net> writes:

> On Mon, May 15, 2017 at 11:12:03AM +0900, Junio C Hamano wrote:
>
>> >> 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
>
> The behavior of cmd_commit() shouldn't be changed by the patch. But to
> make the interface suitable for the new callsite (which doesn't have a
> strbuf, but a ptr/len buffer), it needs to return the length rather than
> shortening the strbuf. We could leave in place:
>
>   void wt_status_truncate_message_at_cut_line(struct strbuf *sb)
>   {
> 	strbuf_setlen(sb, wt_status_last_nonscissors_index(sb->buf, sb->len));
>   }
>
> but it would only have this one caller.
>
> If I were doing the patch series, I'd probably have split that
> refactoring into its own patch and discussed the reason separately. I
> waffled on whether or not to ask Brian to do so (and obviously didn't in
> the end).

I suspect that you would have just explained "since there is only
one caller, let's open-code it" in the log message, without making
this a two-patch series, and that would also have been perfectly
understandable (and in this case probably preferrable).

So the patch text would be OK; it was surprising to have the change
without being explained, that's all.

Thanks.


  reply	other threads:[~2017-05-15  3:32 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
2017-05-15  3:07           ` Jeff King
2017-05-15  3:32             ` Junio C Hamano [this message]
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=xmqqpofax0af.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).