Re: [PATCH v5 1/4] t6006: simplify and optimize empty message test
- From
Elijah Newren <newren@gmail.com>
- Date
- Sep 3, 2019, 21:58 UTC
- Message-ID
- <CABPp-BHx7=kZJ5rgz5q8xRSbVtbE-UEHMyZxjvEq1tRXW7mCzQ@mail.gmail.com>
- In-Reply-To
- <xmqq1rwxt7eu.fsf@gitster-ct.c.googlers.com>
On Tue, Sep 3, 2019 at 2:08 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
>
> Elijah Newren <newren@gmail.com> writes:
>
> > Test t6006.71 ("oneline with empty message") was creating two commits
> > with simple commit messages, and then running filter-branch to rewrite
> > the commit messages to be empty. This test was written this way because
> > the --allow-empty-message option to git commit did not exist at the
> > time. Simplify this test and avoid the need to invoke filter-branch by
> > just using --allow-empty-message when creating the commit.
>
> The result of filter-branch seems to have one empty line as the body
> (i.e. "echo X; git cat-file commit A; echo Y" will show two blank
> lines between the committer line and Y), while "--allow-empty-message"
> does not leave any body (i.e. the same will give you only one blank
> line there).Ah, good catch. I checked out the commit before 1fb5fdd25f0 ("rev-list: fix --pretty=oneline with empty message", 2010-03-21), to try and see the error before that testcase was introduced. I tried it on a repo with both an actual empty commit message, and one with a commit message consisting solely of a newline. Both styles exhibited the bug that the testcase was introduced to guard against.
Show 9 quoted lines
> Was this test verifying the right thing in the first place, I have > to wonder. > > IOW, > > git commit --allow-empty --cleanup=verbatim -m "$LF" && > > would be more faithful conversion of the original (and hopefully > just as performant).
Yeah, it'd be a more faithful conversion of the original, though the original didn't match the testcase description nor the commit message (it claimed it was testing with an empty message). Also, in terms of future proofing, any code changes are more likely to omit a needed trailing LF if the commit message doesn't have one than if it does, so I think it's a more robust test with this change.
I can update the commit message to explain this, or, if you prefer, I could duplicate the testcase and tweak the second as you suggest so we test both with and without the LF. What's your preference?
Show 30 quoted lines
> > Despite only being one piece of the 71st test and there being 73 tests > > overall, this small change to just this one test speeds up the overall > > execution time of t6006 (as measured by the best of 3 runs of `time > > ./t6006-rev-list-format.sh`) by about 11% on Linux, 13% on Mac, and > > about 15% on Windows. > > Quite an improvement ;-) > > > > > Signed-off-by: Elijah Newren <newren@gmail.com> > > --- > > t/t6006-rev-list-format.sh | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh > > index da113d975b..d30e41c9f7 100755 > > --- a/t/t6006-rev-list-format.sh > > +++ b/t/t6006-rev-list-format.sh > > @@ -501,9 +501,8 @@ test_expect_success 'reflog identity' ' > > ' > > > > test_expect_success 'oneline with empty message' ' > > - git commit -m "dummy" --allow-empty && > > - git commit -m "dummy" --allow-empty && > > - git filter-branch --msg-filter "sed -e s/dummy//" HEAD^^.. && > > + git commit --allow-empty --allow-empty-message && > > + git commit --allow-empty --allow-empty-message && > > git rev-list --oneline HEAD >test.txt && > > test_line_count = 5 test.txt && > > git rev-list --oneline --graph HEAD >testg.txt &&