git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood@talktalk.net>
Cc: Git Mailing List <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH] rebase -i: fix numbering in squash message
Date: Wed, 15 Aug 2018 12:17:52 -0700	[thread overview]
Message-ID: <xmqqy3d7h21r.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <27c91e67-7567-f820-c641-c7980965fcef@talktalk.net> (Phillip Wood's message of "Wed, 15 Aug 2018 19:33:31 +0100")

Phillip Wood <phillip.wood@talktalk.net> writes:

>> I wonder if it makes it easier to read, understand and maintain if
>> there were a local variable that gets opts->current_fixup_count+2 at
>> the beginning of the function, make these three places refer to that
>> variable, and move the increment of opts->current_fixup_count down
>> in the function, after the "if we are squashing, do this, if we are
>> fixing up, do that, otherwise, we do not know what we are doing"
>> cascade.  And use the more common post-increment, as we no longer
>> depend on the returned value while at it.
>> 
>> IOW, something like this (untested), on top of yours.
>
> I think you'd need to change commit_staged_changes() as well as it
> relies on the current_fixup_count counting the number of fixups, not the
> number of fixups plus two.

I suspect you misread what I wrote (see below for the patch).  

The fixup_count is a new local variable in update_squash_messages()
that holds N+2; in other words, I am not suggesting to change what
opts->current_fixup_count means.

> Having said that using 'current_fixup_count +
> 2' to create the labels and incrementing the count at the end of
> update_squash_messages() would probably be clearer than my version. I'm
> about to go away so it'll probably be the second week of September
> before I can re-roll this, will that be too late for getting it into 2.19?

I actually do not mind to go with what you originally sent, unless a
cleaned up version is vastly more readable.  After all, a clean-up
can be done separately and safely.

Thanks.

>>  sequencer.c | 10 ++++++----
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>> 
>> diff --git a/sequencer.c b/sequencer.c
>> index 77d3c2346f..f82c283a89 100644
>> --- a/sequencer.c
>> +++ b/sequencer.c
>> @@ -1331,8 +1331,9 @@ static int update_squash_messages(enum todo_command command,
>>  	struct strbuf buf = STRBUF_INIT;
>>  	int res;
>>  	const char *message, *body;
>> +	int fixup_count = opts->current_fixup_count + 2;
>>  
>> -	if (opts->current_fixup_count > 0) {
>> +	if (fixup_count > 2) {
>>  		struct strbuf header = STRBUF_INIT;
>>  		char *eol;
>>  
>> @@ -1345,7 +1346,7 @@ static int update_squash_messages(enum todo_command command,
>>  
>>  		strbuf_addf(&header, "%c ", comment_line_char);
>>  		strbuf_addf(&header, _("This is a combination of %d commits."),
>> -			    opts->current_fixup_count + 2);
>> +			    fixup_count);
>>  		strbuf_splice(&buf, 0, eol - buf.buf, header.buf, header.len);
>>  		strbuf_release(&header);
>>  	} else {
>> @@ -1387,18 +1388,19 @@ static int update_squash_messages(enum todo_command command,
>>  		unlink(rebase_path_fixup_msg());
>>  		strbuf_addf(&buf, "\n%c ", comment_line_char);
>>  		strbuf_addf(&buf, _("This is the commit message #%d:"),
>> -			    ++opts->current_fixup_count + 1);
>> +			    fixup_count);
>>  		strbuf_addstr(&buf, "\n\n");
>>  		strbuf_addstr(&buf, body);
>>  	} else if (command == TODO_FIXUP) {
>>  		strbuf_addf(&buf, "\n%c ", comment_line_char);
>>  		strbuf_addf(&buf, _("The commit message #%d will be skipped:"),
>> -			    ++opts->current_fixup_count + 1);
>> +			    fixup_count);
>>  		strbuf_addstr(&buf, "\n\n");
>>  		strbuf_add_commented_lines(&buf, body, strlen(body));
>>  	} else
>>  		return error(_("unknown command: %d"), command);
>>  	unuse_commit_buffer(commit, message);
>> +	opts->current_fixup_count++;
>>  
>>  	res = write_message(buf.buf, buf.len, rebase_path_squash_msg(), 0);
>>  	strbuf_release(&buf);
>> 
>> 

  reply	other threads:[~2018-08-15 19:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-15  9:41 [PATCH] rebase -i: fix numbering in squash message Phillip Wood
2018-08-15 18:05 ` Junio C Hamano
2018-08-15 18:33   ` Phillip Wood
2018-08-15 19:17     ` Junio C Hamano [this message]
2018-08-16  8:42       ` Johannes Schindelin

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=xmqqy3d7h21r.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=phillip.wood@talktalk.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).