"Simon Gerber via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > t/t9005-help-autocorrect-worktree.sh | 29 ++++++++++++++++++++++++++++ Don't we have existing test script for auto-correction? Is it sensible to waste a new fail for this single test? I doubt it. Perhaps appending after 9003 a new test instead? > diff --git a/t/t9005-help-autocorrect-worktree.sh b/t/t9005-help-autocorrect-worktree.sh > new file mode 100755 > index 00000000000..4fecc8a8e01 > --- /dev/null > +++ b/t/t9005-help-autocorrect-worktree.sh > @@ -0,0 +1,29 @@ > +#!/bin/sh > + > +test_description='test autocorrect in work tree based on bare repository' > +. ./test-lib.sh > + > +test_expect_success 'setup non-bare' ' > + echo one >file && > + git add file && > + git commit -m one && > + echo two >file && > + git commit -a -m two > +' Wouldn't "test_commit" be simpler to use than rolling our own here? If we piggy-back on set-up in an existing test script, there probably is already a history the single test to attempt running 'git staut' can use. After all, that test does not care an iota what is in the history. > + > +test_expect_success 'setup bare' ' > + git clone --bare . bare.git && > + cd bare.git Do not chdir around in a test script, especially in separate steps. > +' > + > +test_expect_success 'setup worktree from bare' ' > + git worktree add ../bare-wt && > + cd ../bare-wt > +' Ditto. Either do it in a subshell in a single step, or ( git clone --bare . bare.git && cd bare.git && git worktree add ../worktree && cd ../worktree && git -c help.autocorrect=immediate staut ) use "git -C <over-there>" form, e.g. git clone --bare . bare.git && git -C bare.git worktree add ../worktree && git -C worktree -c help.autocorrect=immediate staut > +test_expect_success 'autocorrect works in work tree created from bare repo' ' When patch 1/2 is applied without 2/2, this test_expect_success will not be satisfied, breaking future bisection. For a small change like this, have the code change *and* test that verifies the new behaviour in a single step. That way * you do not break bisection. * if somebody wants to cherry-pick the fix to an older maintenance tracks, they can do so by picking a single unit, fix and verification combined together. * acceptance or review can be done by checking the end-result and then tentatively reverting only the code change with something like $ git show -- ':!t/' | git apply -R and see the test that expects success actually fails without the fix.
