On Mon, Aug 4, 2025 at 9:39 PM Patrick Steinhardt [off-list ref] wrote:

On Mon, Aug 04, 2025 at 12:23:49PM -0700, Elijah Newren wrote:

quoted

On Fri, Aug 1, 2025 at 1:31 AM Patrick Steinhardt [off-list ref] wrote:

quoted

On Tue, Jul 22, 2025 at 03:23:09PM +0000, Elijah Newren via GitGitGadget wrote:

quoted

diff --git a/t/t6423-merge-rename-directories.sh b/t/t6423-merge-rename-directories.sh
index 69de7a3b84af..c2032eb6cfa1 100755
--- a/t/t6423-merge-rename-directories.sh
+++ b/t/t6423-merge-rename-directories.sh

@@ -5114,7 +5117,7 @@ test_expect_failure '12n: Directory rename transitively makes rename back to sel
              grep "CONFLICT (file location).*should perhaps be moved" out &&

              # Should have 1 entry for hello, and 1 for world
-             test_stdout_line_count = 2 git ls-files -s &&
+             test_stdout_line_count = 3 git ls-files -s &&
              test_stdout_line_count = 1 git ls-files -s hello &&
              test_stdout_line_count = 2 git ls-files -s world
      )

Should we also explicitly check `git ls-files -s baz`?

Why?  There was no baz in this testcase -- not only did it not appear
in the final commit, it didn't appear in either branch being merged
nor anywhere in the entire history of the repository.  Testcases
12{i,j,k} all had such a file, but testcase 12n does not.

Mostly because the line count was adjusted, so it seems clear to me that
"baz" at least plays a role here. Otherwise there's a mismatch between
the number of lines we see and the state of files we verify.

Oh, oops, the _previous_ patch should have had the change from 2 to 3,
when it also introduced the expectation for 1 copy of hello and 2
copies of world (and marked the test as expecting to fail).  The
comment on the line above should also be fixed.

(However, this still has nothing to do with "baz"; there's no such
file at the toplevel or under any subdirectory -- in any commit in the
repository this testcase is running on -- so it's clear that "baz"
cannot play any kind of role here.  But thanks for flagging this
change -- it definitely got squashed into the wrong patch.)