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