Kong Lucien <Lucien.Kong@xxxxxxxxxxxxxxx> writes: > t/t7060-wtstatus.sh | 2 + > t/t7512-status-warnings.sh | 280 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 282 insertions(+), 0 deletions(-) > diff --git a/t/t7060-wtstatus.sh b/t/t7060-wtstatus.sh > index b8cb490..d9a1e18 100755 > --- a/t/t7060-wtstatus.sh > +++ b/t/t7060-wtstatus.sh > @@ -30,6 +30,8 @@ test_expect_success 'Report new path with conflict' ' > > cat >expect <<EOF > # On branch side > +# You have unmerged paths: fix conflicts and then commit the result. > +# > # Unmerged paths: > # (use "git add/rm <file>..." as appropriate to mark resolution) > # Doesn't the test fail after this if you don't modify the code at the same time? Git's codebase should pass all tests at each commit (if only to allow "git bisect" to run smoothly), so don't modify tests and code in different commits. What you can do on the other hand is to introduce new failing tests (test_expect_failure), and then mark them as success when you update the code. Or introduce tests that show the current behavior, and then patch the expected output when you update the code (the above patch hunk is a nice way to demonstrate the change introduced by the code for example). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html