Re: [PATCH] diff-files: treat "i-t-a" files as "not-in-index"

Srinidhi Kaushik [off-list ref] writes:

quoted

quoted

+     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.