| Message ID | 20190903185524.13467-2-newren@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Warn about git-filter-branch usage and avoid it | expand |
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). 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). > 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 &&
On Tue, Sep 3, 2019 at 2:08 PM Junio C Hamano <gitster@pobox.com> wrote: > > 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. > 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? > > 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 &&
Elijah Newren <newren@gmail.com> writes: > 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. That's a good thing to know to decide what is a reasonable thing to do here. As we are creating two commits, perhaps adding one with and another without the extra blank line may give us more diversity, and explaining why we are adding two slightly different one (i.e. because the original bug was there for both shapes of commits) would help us not wasting the time we already spent discussing this change ;-) Of course, we can alternatively just keep the patch as-is and update the explanation as to why we are testing with commits different from the original when we are supposed to be making this change for performance reasons (i.e. the symptom manifests either way, so why not using the form that is easier to create?). Thanks for working on this ;-)
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 &&
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. 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. Signed-off-by: Elijah Newren <newren@gmail.com> --- t/t6006-rev-list-format.sh | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)