diff mbox series

[RFC,3/9] rebase -i: comment out squash!/fixup! subjects from squash message

Message ID 20210108092345.2178-4-charvi077@gmail.com (mailing list archive)
State Superseded
Headers show
Series rebase -i: add options to fixup command | expand

Commit Message

Charvi Mendiratta Jan. 8, 2021, 9:23 a.m. UTC
From: Phillip Wood <phillip.wood@dunelm.org.uk>

When squashing commit messages the squash!/fixup! subjects are not of
interest so comment them out to stop them becoming part of the final
message.

This change breaks a bunch of --autosquash tests which rely on the
"squash! <subject>" line appearing in the final commit message. This is
addressed by adding a second line to the commit message of the "squash!
..." commits and testing for that.

Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Charvi Mendiratta <charvi077@gmail.com>
---
 sequencer.c                  | 25 ++++++++++++++++++++++++-
 t/t3415-rebase-autosquash.sh | 27 +++++++++++++--------------
 t/t3900-i18n-commit.sh       |  4 ----
 3 files changed, 37 insertions(+), 19 deletions(-)

Comments

Taylor Blau Jan. 13, 2021, 7:01 p.m. UTC | #1
On Fri, Jan 08, 2021 at 02:53:41PM +0530, Charvi Mendiratta wrote:
> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> When squashing commit messages the squash!/fixup! subjects are not of
> interest so comment them out to stop them becoming part of the final
> message.
>
> This change breaks a bunch of --autosquash tests which rely on the
> "squash! <subject>" line appearing in the final commit message. This is
> addressed by adding a second line to the commit message of the "squash!
> ..." commits and testing for that.
>
> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> Signed-off-by: Charvi Mendiratta <charvi077@gmail.com>
> ---
>  sequencer.c                  | 25 ++++++++++++++++++++++++-
>  t/t3415-rebase-autosquash.sh | 27 +++++++++++++--------------
>  t/t3900-i18n-commit.sh       |  4 ----
>  3 files changed, 37 insertions(+), 19 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 5062976d10..b050a9a212 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1718,15 +1718,38 @@ static int is_pick_or_similar(enum todo_command command)
>  	}
>  }
>
> +static size_t subject_length(const char *body)
> +{
> +	size_t i, len = 0;
> +	char c;
> +	int blank_line = 1;
> +	for (i = 0, c = body[i]; c; c = body[++i]) {
> +		if (c == '\n') {
> +			if (blank_line)
> +				return len;
> +			len = i + 1;
> +			blank_line = 1;
> +		} else if (!isspace(c)) {
> +			blank_line = 0;
> +		}
> +	}
> +	return blank_line ? len : i;
> +}
> +

OK, so this gets the length of the subject in "body", which is defined
as the run of characters before a newline and then a space character. So
"foo bar\n\nbaz" would return 7, but "foo bar\nbaz" would return 11.

Makes sense. (Apologies for stating the obvious here, I just had to read
this function to myself a couple of times to make sure that I understood
what it was doing.)

>  static void append_squash_message(struct strbuf *buf, const char *body,
>  				  struct replay_opts *opts)
>  {
> +	size_t commented_len = 0;
> +
>  	unlink(rebase_path_fixup_msg());
> +	if (starts_with(body, "squash!") || starts_with(body, "fixup!"))
> +		commented_len = subject_length(body);
>  	strbuf_addf(buf, "\n%c ", comment_line_char);
>  	strbuf_addf(buf, _("This is the commit message #%d:"),
>  		    ++opts->current_fixup_count + 1);
>  	strbuf_addstr(buf, "\n\n");
> -	strbuf_addstr(buf, body);
> +	strbuf_add_commented_lines(buf, body, commented_len);
> +	strbuf_addstr(buf, body + commented_len);

Very nice; the subject gets commented when it starts with "squash!" or
"fixup!", but the body remains uncommented. Makes sense to me.

> @@ -224,7 +223,7 @@ test_expect_success 'auto squash that matches longer sha1' '
>  	git cat-file blob HEAD^:file1 >actual &&
>  	test_cmp expect actual &&
>  	git cat-file commit HEAD^ >commit &&
> -	grep squash commit >actual &&
> +	grep "extra para" commit >actual &&
>  	test_line_count = 1 actual
>  '

Worth checking that "squash" doesn't appear in an uncommented part of
actual? Or better yet, checking that "# squash ..." _does_ appear.

I.e., that we would leave this as:

    -	grep squash commit >actual &&
    +	grep "^# squash" commit >actual &&
    +	grep "extra para" commit >actual &&

> @@ -342,8 +341,8 @@ test_expect_success C_LOCALE_OUTPUT 'autosquash with custom inst format' '
>  	git cat-file blob HEAD^:file1 >actual &&
>  	test_cmp expect actual &&
>  	git cat-file commit HEAD^ >commit &&
> -	grep squash commit >actual &&
> -	test_line_count = 2 actual
> +	grep first commit >actual &&
> +	test_line_count = 3 actual
>  '

Ditto.

Thanks,
Taylor
Charvi Mendiratta Jan. 14, 2021, 8:27 a.m. UTC | #2
On Thu, 14 Jan 2021 at 00:31, Taylor Blau <me@ttaylorr.com> wrote:
>
> On Fri, Jan 08, 2021 at 02:53:41PM +0530, Charvi Mendiratta wrote:
> > From: Phillip Wood <phillip.wood@dunelm.org.uk>
> >
> > When squashing commit messages the squash!/fixup! subjects are not of
> > interest so comment them out to stop them becoming part of the final
> > message.
> >
> > This change breaks a bunch of --autosquash tests which rely on the
> > "squash! <subject>" line appearing in the final commit message. This is
> > addressed by adding a second line to the commit message of the "squash!
> > ..." commits and testing for that.
> >
> > Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> > Signed-off-by: Charvi Mendiratta <charvi077@gmail.com>
> > ---
> >  sequencer.c                  | 25 ++++++++++++++++++++++++-
> >  t/t3415-rebase-autosquash.sh | 27 +++++++++++++--------------
> >  t/t3900-i18n-commit.sh       |  4 ----
> >  3 files changed, 37 insertions(+), 19 deletions(-)
> >
> > diff --git a/sequencer.c b/sequencer.c
> > index 5062976d10..b050a9a212 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -1718,15 +1718,38 @@ static int is_pick_or_similar(enum todo_command command)
> >       }
> >  }
> >
> > +static size_t subject_length(const char *body)
> > +{
> > +     size_t i, len = 0;
> > +     char c;
> > +     int blank_line = 1;
> > +     for (i = 0, c = body[i]; c; c = body[++i]) {
> > +             if (c == '\n') {
> > +                     if (blank_line)
> > +                             return len;
> > +                     len = i + 1;
> > +                     blank_line = 1;
> > +             } else if (!isspace(c)) {
> > +                     blank_line = 0;
> > +             }
> > +     }
> > +     return blank_line ? len : i;
> > +}
> > +
>
> OK, so this gets the length of the subject in "body", which is defined
> as the run of characters before a newline and then a space character. So
> "foo bar\n\nbaz" would return 7, but "foo bar\nbaz" would return 11.
>
> Makes sense. (Apologies for stating the obvious here, I just had to read
> this function to myself a couple of times to make sure that I understood
> what it was doing.)
>

Earlier while testing patch, I also went through in the same way and
now got confirmed as you described here.

> >  static void append_squash_message(struct strbuf *buf, const char *body,
> >                                 struct replay_opts *opts)
> >  {
> > +     size_t commented_len = 0;
> > +
> >       unlink(rebase_path_fixup_msg());
> > +     if (starts_with(body, "squash!") || starts_with(body, "fixup!"))
> > +             commented_len = subject_length(body);
> >       strbuf_addf(buf, "\n%c ", comment_line_char);
> >       strbuf_addf(buf, _("This is the commit message #%d:"),
> >                   ++opts->current_fixup_count + 1);
> >       strbuf_addstr(buf, "\n\n");
> > -     strbuf_addstr(buf, body);
> > +     strbuf_add_commented_lines(buf, body, commented_len);
> > +     strbuf_addstr(buf, body + commented_len);
>
> Very nice; the subject gets commented when it starts with "squash!" or
> "fixup!", but the body remains uncommented. Makes sense to me.
>

I agree and Thanks to Phillip, for the patch.

> > @@ -224,7 +223,7 @@ test_expect_success 'auto squash that matches longer sha1' '
> >       git cat-file blob HEAD^:file1 >actual &&
> >       test_cmp expect actual &&
> >       git cat-file commit HEAD^ >commit &&
> > -     grep squash commit >actual &&
> > +     grep "extra para" commit >actual &&
> >       test_line_count = 1 actual
> >  '
>
> Worth checking that "squash" doesn't appear in an uncommented part of
> actual? Or better yet, checking that "# squash ..." _does_ appear.
>
> I.e., that we would leave this as:
>
>     -   grep squash commit >actual &&
>     +   grep "^# squash" commit >actual &&
>     +   grep "extra para" commit >actual &&
>
> > @@ -342,8 +341,8 @@ test_expect_success C_LOCALE_OUTPUT 'autosquash with custom inst format' '
> >       git cat-file blob HEAD^:file1 >actual &&
> >       test_cmp expect actual &&
> >       git cat-file commit HEAD^ >commit &&
> > -     grep squash commit >actual &&
> > -     test_line_count = 2 actual
> > +     grep first commit >actual &&
> > +     test_line_count = 3 actual
> >  '
>
> Ditto.

Okay, I will add it .

Thanks and Regards,
Charvi

>
> Thanks,
> Taylor
Phillip Wood Jan. 14, 2021, 10:29 a.m. UTC | #3
Hi Charvi and Taylor

On 14/01/2021 08:27, Charvi Mendiratta wrote:
> On Thu, 14 Jan 2021 at 00:31, Taylor Blau <me@ttaylorr.com> wrote:
>>
>> On Fri, Jan 08, 2021 at 02:53:41PM +0530, Charvi Mendiratta wrote:
>>> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>>>
>>> When squashing commit messages the squash!/fixup! subjects are not of
>>> interest so comment them out to stop them becoming part of the final
>>> message.
>>>
>>> This change breaks a bunch of --autosquash tests which rely on the
>>> "squash! <subject>" line appearing in the final commit message. This is
>>> addressed by adding a second line to the commit message of the "squash!
>>> ..." commits and testing for that.
>>>
>>> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
>>> Signed-off-by: Charvi Mendiratta <charvi077@gmail.com>
>>> ---
>>>   sequencer.c                  | 25 ++++++++++++++++++++++++-
>>>   t/t3415-rebase-autosquash.sh | 27 +++++++++++++--------------
>>>   t/t3900-i18n-commit.sh       |  4 ----
>>>   3 files changed, 37 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/sequencer.c b/sequencer.c
>>> index 5062976d10..b050a9a212 100644
>>> --- a/sequencer.c
>>> +++ b/sequencer.c
>>> @@ -1718,15 +1718,38 @@ static int is_pick_or_similar(enum todo_command command)
>>>        }
>>>   }
>>>
>>> +static size_t subject_length(const char *body)
>>> +{
>>> +     size_t i, len = 0;
>>> +     char c;
>>> +     int blank_line = 1;
>>> +     for (i = 0, c = body[i]; c; c = body[++i]) {
>>> +             if (c == '\n') {
>>> +                     if (blank_line)
>>> +                             return len;
>>> +                     len = i + 1;
>>> +                     blank_line = 1;
>>> +             } else if (!isspace(c)) {
>>> +                     blank_line = 0;
>>> +             }
>>> +     }
>>> +     return blank_line ? len : i;
>>> +}
>>> +
>>
>> OK, so this gets the length of the subject in "body", which is defined
>> as the run of characters before a newline and then a space character.

The length of the subject is the run of characters before a line 
containing only whitespace, "hello\n there" would return 13 "hello\n 
\nthere" would return 5. Looking again at my code there must be a way of 
writing that function that is easier to follow.

>> So
>> "foo bar\n\nbaz" would return 7, but "foo bar\nbaz" would return 11.
>>
>> Makes sense. (Apologies for stating the obvious here, I just had to read
>> this function to myself a couple of times to make sure that I understood
>> what it was doing.)
>>
> 
> Earlier while testing patch, I also went through in the same way and
> now got confirmed as you described here.
> 
>>>   static void append_squash_message(struct strbuf *buf, const char *body,
>>>                                  struct replay_opts *opts)
>>>   {
>>> +     size_t commented_len = 0;
>>> +
>>>        unlink(rebase_path_fixup_msg());
>>> +     if (starts_with(body, "squash!") || starts_with(body, "fixup!"))
>>> +             commented_len = subject_length(body);
>>>        strbuf_addf(buf, "\n%c ", comment_line_char);
>>>        strbuf_addf(buf, _("This is the commit message #%d:"),
>>>                    ++opts->current_fixup_count + 1);
>>>        strbuf_addstr(buf, "\n\n");
>>> -     strbuf_addstr(buf, body);
>>> +     strbuf_add_commented_lines(buf, body, commented_len);
>>> +     strbuf_addstr(buf, body + commented_len);
>>
>> Very nice; the subject gets commented when it starts with "squash!" or
>> "fixup!", but the body remains uncommented. Makes sense to me.
>>
> 
> I agree and Thanks to Phillip, for the patch.
> 
>>> @@ -224,7 +223,7 @@ test_expect_success 'auto squash that matches longer sha1' '
>>>        git cat-file blob HEAD^:file1 >actual &&
>>>        test_cmp expect actual &&
>>>        git cat-file commit HEAD^ >commit &&
>>> -     grep squash commit >actual &&
>>> +     grep "extra para" commit >actual &&
>>>        test_line_count = 1 actual
>>>   '
>>
>> Worth checking that "squash" doesn't appear in an uncommented part of
>> actual? Or better yet, checking that "# squash ..." _does_ appear.
>>
>> I.e., that we would leave this as:
>>
>>      -   grep squash commit >actual &&
>>      +   grep "^# squash" commit >actual &&
>>      +   grep "extra para" commit >actual &&

This test is checking the message that gets committed, not the contents 
of the file passed to the editor. I like the idea of checking that the 
squash! line is indeed commented out, but we'd need to test it with

grep -v squash

Looking at the changes to the tests in this commit it highlights the 
fact that I don't think we ever check exactly what the user sees in 
their editor. We do add such a test for the new `fixup -C` functionality 
in a later patch but perhaps we should improve the test coverage of the 
squash message presented to the user before then.

Best Wishes

Phillip

>>> @@ -342,8 +341,8 @@ test_expect_success C_LOCALE_OUTPUT 'autosquash with custom inst format' '
>>>        git cat-file blob HEAD^:file1 >actual &&
>>>        test_cmp expect actual &&
>>>        git cat-file commit HEAD^ >commit &&
>>> -     grep squash commit >actual &&
>>> -     test_line_count = 2 actual
>>> +     grep first commit >actual &&
>>> +     test_line_count = 3 actual
>>>   '
>>
>> Ditto.
> 
> Okay, I will add it .
> 
> Thanks and Regards,
> Charvi
> 
>>
>> Thanks,
>> Taylor
Charvi Mendiratta Jan. 15, 2021, 8:35 a.m. UTC | #4
Hi Phillip,

On Thu, 14 Jan 2021 at 15:59, Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> Hi Charvi and Taylor
>
> On 14/01/2021 08:27, Charvi Mendiratta wrote:
> > On Thu, 14 Jan 2021 at 00:31, Taylor Blau <me@ttaylorr.com> wrote:
> >>
> >> On Fri, Jan 08, 2021 at 02:53:41PM +0530, Charvi Mendiratta wrote:
> >>> From: Phillip Wood <phillip.wood@dunelm.org.uk>
> >>>
> >>> When squashing commit messages the squash!/fixup! subjects are not of
> >>> interest so comment them out to stop them becoming part of the final
> >>> message.
> >>>
> >>> This change breaks a bunch of --autosquash tests which rely on the
> >>> "squash! <subject>" line appearing in the final commit message. This is
> >>> addressed by adding a second line to the commit message of the "squash!
> >>> ..." commits and testing for that.
> >>>
> >>> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> >>> Signed-off-by: Charvi Mendiratta <charvi077@gmail.com>
> >>> ---
> >>>   sequencer.c                  | 25 ++++++++++++++++++++++++-
> >>>   t/t3415-rebase-autosquash.sh | 27 +++++++++++++--------------
> >>>   t/t3900-i18n-commit.sh       |  4 ----
> >>>   3 files changed, 37 insertions(+), 19 deletions(-)
> >>>
> >>> diff --git a/sequencer.c b/sequencer.c
> >>> index 5062976d10..b050a9a212 100644
> >>> --- a/sequencer.c
> >>> +++ b/sequencer.c
> >>> @@ -1718,15 +1718,38 @@ static int is_pick_or_similar(enum todo_command command)
> >>>        }
> >>>   }
> >>>
> >>> +static size_t subject_length(const char *body)
> >>> +{
> >>> +     size_t i, len = 0;
> >>> +     char c;
> >>> +     int blank_line = 1;
> >>> +     for (i = 0, c = body[i]; c; c = body[++i]) {
> >>> +             if (c == '\n') {
> >>> +                     if (blank_line)
> >>> +                             return len;
> >>> +                     len = i + 1;
> >>> +                     blank_line = 1;
> >>> +             } else if (!isspace(c)) {
> >>> +                     blank_line = 0;
> >>> +             }
> >>> +     }
> >>> +     return blank_line ? len : i;
> >>> +}
> >>> +
> >>
> >> OK, so this gets the length of the subject in "body", which is defined
> >> as the run of characters before a newline and then a space character.
>
> The length of the subject is the run of characters before a line
> containing only whitespace, "hello\n there" would return 13 "hello\n
> \nthere" would return 5. Looking again at my code there must be a way of
> writing that function that is easier to follow.
>

Okay. I will look into it once, thanks for explaining.

> >> So
> >> "foo bar\n\nbaz" would return 7, but "foo bar\nbaz" would return 11.
> >>
> >> Makes sense. (Apologies for stating the obvious here, I just had to read
> >> this function to myself a couple of times to make sure that I understood
> >> what it was doing.)
> >>
> >
> > Earlier while testing patch, I also went through in the same way and
> > now got confirmed as you described here.
> >
> >>>   static void append_squash_message(struct strbuf *buf, const char *body,
> >>>                                  struct replay_opts *opts)
> >>>   {
> >>> +     size_t commented_len = 0;
> >>> +
> >>>        unlink(rebase_path_fixup_msg());
> >>> +     if (starts_with(body, "squash!") || starts_with(body, "fixup!"))
> >>> +             commented_len = subject_length(body);
> >>>        strbuf_addf(buf, "\n%c ", comment_line_char);
> >>>        strbuf_addf(buf, _("This is the commit message #%d:"),
> >>>                    ++opts->current_fixup_count + 1);
> >>>        strbuf_addstr(buf, "\n\n");
> >>> -     strbuf_addstr(buf, body);
> >>> +     strbuf_add_commented_lines(buf, body, commented_len);
> >>> +     strbuf_addstr(buf, body + commented_len);
> >>
> >> Very nice; the subject gets commented when it starts with "squash!" or
> >> "fixup!", but the body remains uncommented. Makes sense to me.
> >>
> >
> > I agree and Thanks to Phillip, for the patch.
> >
> >>> @@ -224,7 +223,7 @@ test_expect_success 'auto squash that matches longer sha1' '
> >>>        git cat-file blob HEAD^:file1 >actual &&
> >>>        test_cmp expect actual &&
> >>>        git cat-file commit HEAD^ >commit &&
> >>> -     grep squash commit >actual &&
> >>> +     grep "extra para" commit >actual &&
> >>>        test_line_count = 1 actual
> >>>   '
> >>
> >> Worth checking that "squash" doesn't appear in an uncommented part of
> >> actual? Or better yet, checking that "# squash ..." _does_ appear.
> >>
> >> I.e., that we would leave this as:
> >>
> >>      -   grep squash commit >actual &&
> >>      +   grep "^# squash" commit >actual &&
> >>      +   grep "extra para" commit >actual &&
>
> This test is checking the message that gets committed, not the contents
> of the file passed to the editor. I like the idea of checking that the
> squash! line is indeed commented out, but we'd need to test it with
>
> grep -v squash
>
> Looking at the changes to the tests in this commit it highlights the
> fact that I don't think we ever check exactly what the user sees in
> their editor. We do add such a test for the new `fixup -C` functionality
> in a later patch but perhaps we should improve the test coverage of the
> squash message presented to the user before then.
>

Okay and for checking "squash" I will add it in the above way.

Thanks and Regards,
Charvi


> Best Wishes
>
> Phillip
>
> >>> @@ -342,8 +341,8 @@ test_expect_success C_LOCALE_OUTPUT 'autosquash with custom inst format' '
> >>>        git cat-file blob HEAD^:file1 >actual &&
> >>>        test_cmp expect actual &&
> >>>        git cat-file commit HEAD^ >commit &&
> >>> -     grep squash commit >actual &&
> >>> -     test_line_count = 2 actual
> >>> +     grep first commit >actual &&
> >>> +     test_line_count = 3 actual
> >>>   '
> >>
> >> Ditto.
> >
> > Okay, I will add it .
> >
> > Thanks and Regards,
> > Charvi
> >
> >>
> >> Thanks,
> >> Taylor
>
Christian Couder Jan. 15, 2021, 8:44 a.m. UTC | #5
Hi Charvi,

On Fri, Jan 15, 2021 at 9:35 AM Charvi Mendiratta <charvi077@gmail.com> wrote:

> On Thu, 14 Jan 2021 at 15:59, Phillip Wood <phillip.wood123@gmail.com> wrote:

> > On 14/01/2021 08:27, Charvi Mendiratta wrote:
> > > On Thu, 14 Jan 2021 at 00:31, Taylor Blau <me@ttaylorr.com> wrote:
> > >>
> > >> On Fri, Jan 08, 2021 at 02:53:41PM +0530, Charvi Mendiratta wrote:
> > >>> From: Phillip Wood <phillip.wood@dunelm.org.uk>

> > >>> +static size_t subject_length(const char *body)
> > >>> +{
> > >>> +     size_t i, len = 0;
> > >>> +     char c;
> > >>> +     int blank_line = 1;
> > >>> +     for (i = 0, c = body[i]; c; c = body[++i]) {
> > >>> +             if (c == '\n') {
> > >>> +                     if (blank_line)
> > >>> +                             return len;
> > >>> +                     len = i + 1;
> > >>> +                     blank_line = 1;
> > >>> +             } else if (!isspace(c)) {
> > >>> +                     blank_line = 0;
> > >>> +             }
> > >>> +     }
> > >>> +     return blank_line ? len : i;
> > >>> +}
> > >>
> > >> OK, so this gets the length of the subject in "body", which is defined
> > >> as the run of characters before a newline and then a space character.
> >
> > The length of the subject is the run of characters before a line
> > containing only whitespace, "hello\n there" would return 13 "hello\n
> > \nthere" would return 5. Looking again at my code there must be a way of
> > writing that function that is easier to follow.
>
> Okay. I will look into it once, thanks for explaining.

You may want to look at other places in the code where we deal with
the subject. For example there is find_commit_subject() in commit.c
and find_trailer_start() in trailer.c that might have interesting code
for our purpose.

Best,
Christian.
Charvi Mendiratta Jan. 15, 2021, 11:12 a.m. UTC | #6
Hi Christian,

On Fri, 15 Jan 2021 at 14:15, Christian Couder
<christian.couder@gmail.com> wrote:
>
> Hi Charvi,
>
> On Fri, Jan 15, 2021 at 9:35 AM Charvi Mendiratta <charvi077@gmail.com> wrote:
>
> > On Thu, 14 Jan 2021 at 15:59, Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> > > On 14/01/2021 08:27, Charvi Mendiratta wrote:
> > > > On Thu, 14 Jan 2021 at 00:31, Taylor Blau <me@ttaylorr.com> wrote:
> > > >>
> > > >> On Fri, Jan 08, 2021 at 02:53:41PM +0530, Charvi Mendiratta wrote:
> > > >>> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> > > >>> +static size_t subject_length(const char *body)
> > > >>> +{
> > > >>> +     size_t i, len = 0;
> > > >>> +     char c;
> > > >>> +     int blank_line = 1;
> > > >>> +     for (i = 0, c = body[i]; c; c = body[++i]) {
> > > >>> +             if (c == '\n') {
> > > >>> +                     if (blank_line)
> > > >>> +                             return len;
> > > >>> +                     len = i + 1;
> > > >>> +                     blank_line = 1;
> > > >>> +             } else if (!isspace(c)) {
> > > >>> +                     blank_line = 0;
> > > >>> +             }
> > > >>> +     }
> > > >>> +     return blank_line ? len : i;
> > > >>> +}
> > > >>
> > > >> OK, so this gets the length of the subject in "body", which is defined
> > > >> as the run of characters before a newline and then a space character.
> > >
> > > The length of the subject is the run of characters before a line
> > > containing only whitespace, "hello\n there" would return 13 "hello\n
> > > \nthere" would return 5. Looking again at my code there must be a way of
> > > writing that function that is easier to follow.
> >
> > Okay. I will look into it once, thanks for explaining.
>
> You may want to look at other places in the code where we deal with
> the subject. For example there is find_commit_subject() in commit.c
> and find_trailer_start() in trailer.c that might have interesting code
> for our purpose.
>

Thanks for the pointer, I will look at it.

Thanks and Regards,
Charvi

> Best,
> Christian.
Charvi Mendiratta Jan. 17, 2021, 3:39 a.m. UTC | #7
Hi Phillip and Taylor,

> [...]
> >>> @@ -224,7 +223,7 @@ test_expect_success 'auto squash that matches longer sha1' '
> >>>        git cat-file blob HEAD^:file1 >actual &&
> >>>        test_cmp expect actual &&
> >>>        git cat-file commit HEAD^ >commit &&
> >>> -     grep squash commit >actual &&
> >>> +     grep "extra para" commit >actual &&
> >>>        test_line_count = 1 actual
> >>>   '
> >>
> >> Worth checking that "squash" doesn't appear in an uncommented part of
> >> actual? Or better yet, checking that "# squash ..." _does_ appear.
> >>
> >> I.e., that we would leave this as:
> >>
> >>      -   grep squash commit >actual &&
> >>      +   grep "^# squash" commit >actual &&
> >>      +   grep "extra para" commit >actual &&
>
> This test is checking the message that gets committed, not the contents
> of the file passed to the editor. I like the idea of checking that the
> squash! line is indeed commented out, but we'd need to test it with
>
> grep -v squash
>

It seems to me that you suggest to use 'grep -v squash' instead of
grep "^#squash". So I added to check the test as here:

             -   grep squash commit >actual &&
             +   grep -v "squash" commit >actual &&
             +   grep "extra para" commit >actual &&

> Looking at the changes to the tests in this commit it highlights the
> fact that I don't think we ever check exactly what the user sees in
> their editor. We do add such a test for the new `fixup -C` functionality
> in a later patch but perhaps we should improve the test coverage of the
> squash message presented to the user before then.

I agree and in this test  it's now just checking if the commit message body of
"squash!" i.e  line "extra para", is added in commit message or not. So, I am
doubtful if the above is the right way to test whether squash! line is commented
out or not , as "grep "extra para" commit >actual &&" will rewrite the
'actual' file.

Thanks and Regards,
Charvi
Phillip Wood Jan. 18, 2021, 6:29 p.m. UTC | #8
Hi Charvi

On 17/01/2021 03:39, Charvi Mendiratta wrote:
> Hi Phillip and Taylor,
> 
>> [...]
>>>>> @@ -224,7 +223,7 @@ test_expect_success 'auto squash that matches longer sha1' '
>>>>>         git cat-file blob HEAD^:file1 >actual &&
>>>>>         test_cmp expect actual &&
>>>>>         git cat-file commit HEAD^ >commit &&
>>>>> -     grep squash commit >actual &&
>>>>> +     grep "extra para" commit >actual &&
>>>>>         test_line_count = 1 actual
>>>>>    '
>>>>
>>>> Worth checking that "squash" doesn't appear in an uncommented part of
>>>> actual? Or better yet, checking that "# squash ..." _does_ appear.
>>>>
>>>> I.e., that we would leave this as:
>>>>
>>>>       -   grep squash commit >actual &&
>>>>       +   grep "^# squash" commit >actual &&
>>>>       +   grep "extra para" commit >actual &&
>>
>> This test is checking the message that gets committed, not the contents
>> of the file passed to the editor. I like the idea of checking that the
>> squash! line is indeed commented out, but we'd need to test it with
>>
>> grep -v squash
>>
> 
> It seems to me that you suggest to use 'grep -v squash' instead of
> grep "^#squash".

That's correct

> So I added to check the test as here:
> 
>               -   grep squash commit >actual &&
>               +   grep -v "squash" commit >actual &&

There is no need to redirect the output of this one - we don't expect 
any output and the test will fail if there is so we want to see what the 
output is.

>               +   grep "extra para" commit >actual &&
> 
>> Looking at the changes to the tests in this commit it highlights the
>> fact that I don't think we ever check exactly what the user sees in
>> their editor. We do add such a test for the new `fixup -C` functionality
>> in a later patch but perhaps we should improve the test coverage of the
>> squash message presented to the user before then.
> 
> I agree and in this test  it's now just checking if the commit message body of
> "squash!" i.e  line "extra para", is added in commit message or not. So, I am
> doubtful if the above is the right way to test whether squash! line is commented
> out or not , as "grep "extra para" commit >actual &&" will rewrite the
> 'actual' file.

The test above gives us reassurance that "squash! ..." does not make it 
into the commit message which is important. We'd want a separate test to 
check the message that is presented to the user however looking at patch 
7 the test 'sequence of fixup, fixup -C & squash --signoff works' checks 
that a "squash! ..." subject line gets commented out so I wouldn't worry 
about an additional test here

Best Wishes

Phillip

> Thanks and Regards,
> Charvi
>
Charvi Mendiratta Jan. 19, 2021, 4:08 a.m. UTC | #9
Hi Phillip,

On Mon, 18 Jan 2021 at 23:59, Phillip Wood <phillip.wood123@gmail.com> wrote:
> [...]
> > So I added to check the test as here:
> >
> >               -   grep squash commit >actual &&
> >               +   grep -v "squash" commit >actual &&
>
> There is no need to redirect the output of this one - we don't expect
> any output and the test will fail if there is so we want to see what the
> output is.
>

Okay,

> >               +   grep "extra para" commit >actual &&
> >
> >> Looking at the changes to the tests in this commit it highlights the
> >> fact that I don't think we ever check exactly what the user sees in
> >> their editor. We do add such a test for the new `fixup -C` functionality
> >> in a later patch but perhaps we should improve the test coverage of the
> >> squash message presented to the user before then.
> >
> > I agree and in this test  it's now just checking if the commit message body of
> > "squash!" i.e  line "extra para", is added in commit message or not. So, I am
> > doubtful if the above is the right way to test whether squash! line is commented
> > out or not , as "grep "extra para" commit >actual &&" will rewrite the
> > 'actual' file.
>
> The test above gives us reassurance that "squash! ..." does not make it
> into the commit message which is important. We'd want a separate test to
> check the message that is presented to the user however looking at patch
> 7 the test 'sequence of fixup, fixup -C & squash --signoff works' checks
> that a "squash! ..." subject line gets commented out so I wouldn't worry
> about an additional test here

I agree, thanks for confirming.

Thanks and Regards,
Charvi
diff mbox series

Patch

diff --git a/sequencer.c b/sequencer.c
index 5062976d10..b050a9a212 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1718,15 +1718,38 @@  static int is_pick_or_similar(enum todo_command command)
 	}
 }
 
+static size_t subject_length(const char *body)
+{
+	size_t i, len = 0;
+	char c;
+	int blank_line = 1;
+	for (i = 0, c = body[i]; c; c = body[++i]) {
+		if (c == '\n') {
+			if (blank_line)
+				return len;
+			len = i + 1;
+			blank_line = 1;
+		} else if (!isspace(c)) {
+			blank_line = 0;
+		}
+	}
+	return blank_line ? len : i;
+}
+
 static void append_squash_message(struct strbuf *buf, const char *body,
 				  struct replay_opts *opts)
 {
+	size_t commented_len = 0;
+
 	unlink(rebase_path_fixup_msg());
+	if (starts_with(body, "squash!") || starts_with(body, "fixup!"))
+		commented_len = subject_length(body);
 	strbuf_addf(buf, "\n%c ", comment_line_char);
 	strbuf_addf(buf, _("This is the commit message #%d:"),
 		    ++opts->current_fixup_count + 1);
 	strbuf_addstr(buf, "\n\n");
-	strbuf_addstr(buf, body);
+	strbuf_add_commented_lines(buf, body, commented_len);
+	strbuf_addstr(buf, body + commented_len);
 }
 
 static int update_squash_messages(struct repository *r,
diff --git a/t/t3415-rebase-autosquash.sh b/t/t3415-rebase-autosquash.sh
index 7bab6000dc..45fe6a227e 100755
--- a/t/t3415-rebase-autosquash.sh
+++ b/t/t3415-rebase-autosquash.sh
@@ -81,8 +81,7 @@  test_auto_squash () {
 	echo 1 >file1 &&
 	git add -u &&
 	test_tick &&
-	git commit -m "squash! first" &&
-
+	git commit -m "squash! first" -m "extra para for first" &&
 	git tag $1 &&
 	test_tick &&
 	git rebase $2 -i HEAD^^^ &&
@@ -139,7 +138,7 @@  test_expect_success 'auto squash that matches 2 commits' '
 	echo 1 >file1 &&
 	git add -u &&
 	test_tick &&
-	git commit -m "squash! first" &&
+	git commit -m "squash! first" -m "extra para for first" &&
 	git tag final-multisquash &&
 	test_tick &&
 	git rebase --autosquash -i HEAD~4 &&
@@ -192,7 +191,7 @@  test_expect_success 'auto squash that matches a sha1' '
 	git add -u &&
 	test_tick &&
 	oid=$(git rev-parse --short HEAD^) &&
-	git commit -m "squash! $oid" &&
+	git commit -m "squash! $oid" -m "extra para" &&
 	git tag final-shasquash &&
 	test_tick &&
 	git rebase --autosquash -i HEAD^^^ &&
@@ -203,7 +202,7 @@  test_expect_success 'auto squash that matches a sha1' '
 	git cat-file blob HEAD^:file1 >actual &&
 	test_cmp expect actual &&
 	git cat-file commit HEAD^ >commit &&
-	grep squash commit >actual &&
+	grep "extra para" commit >actual &&
 	test_line_count = 1 actual
 '
 
@@ -213,7 +212,7 @@  test_expect_success 'auto squash that matches longer sha1' '
 	git add -u &&
 	test_tick &&
 	oid=$(git rev-parse --short=11 HEAD^) &&
-	git commit -m "squash! $oid" &&
+	git commit -m "squash! $oid" -m "extra para" &&
 	git tag final-longshasquash &&
 	test_tick &&
 	git rebase --autosquash -i HEAD^^^ &&
@@ -224,7 +223,7 @@  test_expect_success 'auto squash that matches longer sha1' '
 	git cat-file blob HEAD^:file1 >actual &&
 	test_cmp expect actual &&
 	git cat-file commit HEAD^ >commit &&
-	grep squash commit >actual &&
+	grep "extra para" commit >actual &&
 	test_line_count = 1 actual
 '
 
@@ -233,7 +232,7 @@  test_auto_commit_flags () {
 	echo 1 >file1 &&
 	git add -u &&
 	test_tick &&
-	git commit --$1 first-commit &&
+	git commit --$1 first-commit -m "extra para for first" &&
 	git tag final-commit-$1 &&
 	test_tick &&
 	git rebase --autosquash -i HEAD^^^ &&
@@ -261,11 +260,11 @@  test_auto_fixup_fixup () {
 	echo 1 >file1 &&
 	git add -u &&
 	test_tick &&
-	git commit -m "$1! first" &&
+	git commit -m "$1! first" -m "extra para for first" &&
 	echo 2 >file1 &&
 	git add -u &&
 	test_tick &&
-	git commit -m "$1! $2! first" &&
+	git commit -m "$1! $2! first" -m "second extra para for first" &&
 	git tag "final-$1-$2" &&
 	test_tick &&
 	(
@@ -326,12 +325,12 @@  test_expect_success C_LOCALE_OUTPUT 'autosquash with custom inst format' '
 	git add -u &&
 	test_tick &&
 	oid=$(git rev-parse --short HEAD^) &&
-	git commit -m "squash! $oid" &&
+	git commit -m "squash! $oid" -m "extra para for first" &&
 	echo 1 >file1 &&
 	git add -u &&
 	test_tick &&
 	subject=$(git log -n 1 --format=%s HEAD~2) &&
-	git commit -m "squash! $subject" &&
+	git commit -m "squash! $subject" -m "second extra para for first" &&
 	git tag final-squash-instFmt &&
 	test_tick &&
 	git rebase --autosquash -i HEAD~4 &&
@@ -342,8 +341,8 @@  test_expect_success C_LOCALE_OUTPUT 'autosquash with custom inst format' '
 	git cat-file blob HEAD^:file1 >actual &&
 	test_cmp expect actual &&
 	git cat-file commit HEAD^ >commit &&
-	grep squash commit >actual &&
-	test_line_count = 2 actual
+	grep first commit >actual &&
+	test_line_count = 3 actual
 '
 
 test_expect_success 'autosquash with empty custom instructionFormat' '
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index d277a9f4b7..bfab245eb3 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -226,10 +226,6 @@  test_commit_autosquash_multi_encoding () {
 		git rev-list HEAD >actual &&
 		test_line_count = 3 actual &&
 		iconv -f $old -t UTF-8 "$TEST_DIRECTORY"/t3900/$msg >expect &&
-		if test $flag = squash; then
-			subject="$(head -1 expect)" &&
-			printf "\nsquash! %s\n" "$subject" >>expect
-		fi &&
 		git cat-file commit HEAD^ >raw &&
 		(sed "1,/^$/d" raw | iconv -f $new -t utf-8) >actual &&
 		test_cmp expect actual