git 无法暂存文件，将所有文件显示为重复但 char 大小写不是问题

Question

在我的例子中，我对我的一个文件做了简单的一行更改，并想提交我的更改，但注意到 commit -am ""没有添加/提交文件。

发出 git ls-files --stage 后，我发现我项目中的所有文件可能都显示为重复项。这是其中一个文件的示例

100644 6314bd3f89d1b794c6d8c0fb9bb4aa492e2d510a 0   SquirrelFoH/Squirrel.FoH.ViewModels/UserLoginViewModel.cs
100644 6314bd3f89d1b794c6d8c0fb9bb4aa492e2d510a 0   SquirrelFoH/Squirrel.FoH.ViewModels/UserLoginViewModel.cs

有趣的是，一些显示广告重复的文件根本没有被我修改，有些是但是，它们显示为重复，正如您在下面看到的那样，外壳不是这里其他 SO 帖子中的问题。

更新

虽然这没有解决我的上述问题，但它帮助我使用 git reset --hard HEAD~1 将 HEAD 指针重置为倒数第二个提交，这是有效的提交。我使用上面的 --hard 丢弃最后一次提交，因为它对我造成了上面的问题。如果您需要保留这些更改，请改用 --soft 将 HEAD 重置为上次提交之前的提交，并将上次提交中的更改添加到暂存区。

git reset --hard HEAD~1
git reset --hard HEAD~2
git reset --hard HEAD~3
...

以上命令重置 HEAD 指针 1, 2, 3, ... 在上次提交之前提交并丢弃之后的任何更改。如果您不想放弃这些更改，请使用 --soft 而不是 --hard，在这种情况下，将为您准备这些更改。

这就是我遇到的情况。下面，最后一次提交是提交 A，它是在最后一次将远程更改 pull 入我的本地分支后开始出现重复项的提交。提交 B、C、... 是提交 A 之前的提交:

commit A
commit B - git reseat --hard HEAD~1
commit C 

，现在我的最后一次提交是没有重复的提交 B。我现在可以再次尝试 merge ，看看我是否会遇到与提交 A 相同的问题。正如我提到的，这并不能解决问题，但至少允许我尝试重新创建它或继续我的工作并处理稍后 merge 。

Answer 1

您将必须检查 Git 2.22.1(Q3 2019)/Git 2.25(Q1 2020)中是否仍然存在该问题，因为 fsmonitor 收集的数据未正确写回-磁盘索引文件(在 Mac、Linux 或 Windows 上)

参见 commit b5a8169 , commit d4c0a3a (2019 年 5 月 24 日)Johannes Schindelin (dscho) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit 10432cc ，2019 年 7 月 25 日)}

mark_fsmonitor_valid(): mark the index as changed if needed

Without this bug fix, t7519's four "status doesn't detect unreported modifications" test cases would fail occasionally (and, oddly enough, a lot more frequently on Windows).

The reason is that these test cases intentionally use the side effect of git status to re-write the index if any updates were detected: they first clean the worktree, run git status to update the index as well as show the output to the casual reader, then make the worktree dirty again and expect no changes to reported if running with a mocked fsmonitor hook.

The problem with this strategy was that the index was written during said git status on the clean worktree for the wrong reason: not because the index was marked as changed (it wasn't), but because the recorded mtimes were racy with the index' own mtime.

As the mtime granularity on Windows is 100 nanoseconds (see e.g. https://learn.microsoft.com/en-us/windows/desktop/SysInfo/file-times), the mtimes of the files are often enough not racy with the index', so that that git status call currently does not always update the index (including the fsmonitor extension), causing the test case to fail.

The obvious fix: if we change any index entry's CE_FSMONITOR_VALID flag, we should also mark the index as changed.
That will cause the index to be written upon git status, including an updated fsmonitor extension.

Side note: Even though the reader might think that the t7519 issue should be much more prevalent on Linux, given that the ext4 filesystem (that seems to be used by every Linux distribution) stores mtimes in nanosecond precision. However, ext4 uses current_kernel_time() (see https://unix.stackexchange.com/questions/11599#comment762968_11599; it is amazingly hard to find any proper source of information about such ext4 questions) whose accuracy seems to depend on many factors but is safely worse than the 100-nanosecond granularity of NTFS (again, it is horribly hard to find anything remotely authoritative about this question). So it seems that the racy index condition that hid the bug fixed by this patch simply is a lot more likely on Linux than on Windows. But not impossible ;-)

---

在 Git 2.25(2020 年第一季度)中，fsmonitor 更加健壮，并删除了不应触发的错误 BUG()。

参见 commit 61eea52 (2019 年 11 月 13 日)Junio C Hamano (gitster) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit aec3b2e ，2019 年 12 月 1 日)}

fsmonitor: do not compare bitmap size with size of split index

^{Reported-by: Utsav Shah
Helped-by: Kevin Willford
Helped-by: William Baker}

3444ec2e ("fsmonitor: don't fill bitmap with entries to be removed", 2019-10-11, Git v2.24.0-rc1 -- merge listed in batch #11) added a handful of sanity checks that make sure that a bit position in fsmonitor bitmap does not go beyond the end of the index.

As each bit in the bitmap corresponds to a path in the index, this is the right check most of the time.

Except for the case when we are in the split-index mode and looking at a delta index that is to be overlayed on the base index but before the base index has actually been merged in, namely in read_ and write_fsmonitor_extension().

In these codepaths, the entries in the split/delta index is typically a small subset of the entire set of paths (otherwise why would we be using split-index?), so the bitmap used by the fsmonitor is almost always larger than the number of entries in the partial index, and the incorrect comparison would trigger the BUG().