Re: [PATCH v7 0/2] diff-files: integrate with sparse index

Shuqi Liang wrote:

While they'll (ideally) give the same user-facing result, there is a difference in how they exercise 'diff-files' because of how 'update-index --refresh' will affect SKIP_WORKTREE and sparse directories.

Using the same scenario you've set up for your test, suppose I start with a fresh copy of the 't1092' repo. In the 'sparse-index' repo copy, 'folder1/' will be a sparse directory:

$ git ls-files -t --sparse folder1/ S folder1/

(note: "S" indicates that SKIP_WORKTREE is applied to the entry)

Now suppose I copy 'a' into 'folder1/' and run 'update-index --refresh' then 'ls-files' again:

$ git update-index --refresh $ git ls-files -t --sparse folder1/ S folder1/0/ H folder1/a

(note: "H" indicates that 'folder1/a' does not have SKIP_WORKTREE applied)

The sparse directory has been expanded and SKIP_WORKTREE has been removed from the file that's now present on-disk. This was an intentional "safety" measure added in [1] to address the growing volume of bugs and complexities in scenarios where SKIP_WORKTREE files existed on disk.

Ultimately, the main difference between this test with & without 'update-index' is who applies those index corrections when initially reading the index: 'update-index' or 'diff-files'. I lean towards the latter because the former is tested (almost identically) in 'update-index modify outside sparse definition' earlier in 't1092'.

[1] https://lore.kernel.org/git/pull.1114.v2.git.1642175983.gitgitgadget@gmail.com/

More or less, yes. Internally, 'diff-files' will "see" the file creation differences, but the '--stat' format doesn't print them.

This isn't quite true - 'update-index' only updates the *contents* of index entries (or, colloquially, "stage them for commit") for files explicitly provided as arguments. Separately, though, '--refresh' updates *all* index entries' cached 'stat' information.

Going a bit deeper: with no arguments, 'update-index' will read the index, do nothing to it, then write it only if something has changed. In almost all cases, reading the index doesn't cause any changes to it, making it a no-op. However, the removal of SKIP_WORKTREE is done on read (including a refresh of the entry's stat information), so a even plain 'update-index' *without* '--refresh' would write a modified index to disk. In your test, that means:

	run_on_sparse mkdir -p folder1 &&
	run_on_sparse cp a folder1/a &&
	run_on_all git update-index &&
	test_all_match git diff-files

would get you the same result as:

	run_on_sparse mkdir -p folder1 &&
	run_on_sparse cp a folder1/a &&
	run_on_all git update-index --refresh &&
	test_all_match git diff-files

I hope the above explanation is helpful. I still think '--stat' is the best way to test this case, but I'm interested to hear your/others' thoughts on the matter given the additional context.