Hi Junio On Thu, Mar 23, 2023 at 12:03 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > When the index file is not up-to-date, git diff-files may show differences > > between the working directory and the index that are caused by file creation > > time differences, rather than actual changes to the file contents. By using git > > diff-files --stat, which ignores file creation time differences. > > Use of "diff-files --stat" would mean that the contents of the blob > registered in the index will be inspected, which can be used to hide > the "stat dirty" condition. > > But doesn't it cut both ways? Starting from a clean index that has > up-to-date stat information for paths, we may want to test what > "stat dirty" changes diff-files reports when we touch paths in the > working tree, both inside and outside the spase cones. A test with > "--stat" will not achieve that, exactly because it does not pay > attention to and hides the stat dirtiness. In this case, we can only use 'git diff-files --stat' when files are present on disk without modifications. Since we know in the full-checkout case 'diff-files --stat' will give empty output, so sparse-checkout and sparse-index are also empty. These make sure that the paths in the working tree are not dirty. So we do not need to pay attention to 'stat dirty' change. When 'file present on-disk with modifications'. We use 'git diff-files' instead of 'git diff-files --stat' so we can get the expected "modified" status but avoids potential breakages related to inconsistency in the file creation time. # file present on-disk without modifications # use `--stat` to ignore file creation time differences in # unrefreshed index test_all_match git diff-files --stat && test_all_match git diff-files --stat folder1/a && test_all_match git diff-files --stat "folder*/a" && # file present on-disk with modifications run_on_all ../edit-contents folder1/a && test_all_match git diff-files && test_all_match git diff-files folder1/a && test_all_match git diff-files "folder*/a" > On the other hand, if "update-index --refresh" is used in the test, > we may discover breakages caused by "update-index" not handling > the sparse index correctly. It would be outside the topic of this > series, so avoiding it would be simpler, but (1) if it is not broken, > then as you said, it would be a more direct way to test diff-files, > and (2) if it is broken, it would need to be fixed anyway, before or > after this series. So, I dunno... Thanks Shuqi
