Srinidhi Kaushik <shrinidhi.kaushik@xxxxxxxxx> writes: >> > + git add -N empty not-empty && >> > + git diff-files -p >actual && >> > + hash_e=$(git hash-object empty) && >> > + hash_n=$(git hash-object not-empty) && >> > + cat >expect <<-EOF && >> > + diff --git a/empty b/empty >> > + new file mode 100644 >> > + index 0000000..$(git rev-parse --short $hash_e) >> > + diff --git a/not-empty b/not-empty >> > + new file mode 100644 >> > + index 0000000..$(git rev-parse --short $hash_n) >> > + --- /dev/null >> > + +++ b/not-empty >> > + @@ -0,0 +1 @@ >> > + +$content >> > + EOF >> > + test_cmp expect actual >> > +' >> >> OK. Do we want to show what happens when "diff" and "diff --cached" >> are run with these two "added but not quite added yet" paths to >> contrast with this new case? > > I'm not sure if we want to repeat an older test. The test (which was > renamed in this patch) in t2203-add-intent.sh: "diff/diff-cached shows > ita as new/not-new files" is already doing that. Should the "diff" and > "diff --cached" steps be appended here again? No, there is no need to repeat essentially the same test that exists elsewhere. I wonder if it reduces duplication even further if we extend that existing test that checks "diff" and "diff --cached" so that it also checks "diff-files" as well?, instead of adding this new one? The existing one checks diff and diff-cached only with a new non-empty path, and it can use tests with a new empty path at the same time, with a unified "set up" code that is in the early part of the test, e.g. diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh index 5bbe8dcce4..cfde790ac7 100755 --- a/t/t2203-add-intent.sh +++ b/t/t2203-add-intent.sh @@ -235,7 +235,8 @@ test_expect_success 'double rename detection in status' ' test_expect_success 'diff-files/diff-cached shows ita as new/not-new files' ' git reset --hard && echo new >new-ita && - git add -N new-ita && + : >new-ita-empty && + git add -N new-ita new-ita-empty && git diff --summary >actual && ... Then the existing tests can be updated to see not just --summary but also for the contents like you did in the new test---and another test that examines what "git diff-files" sees (which is what you added) can happen in the same test (that way, the same set-up can be reused for three tests). Thanks.
