git无法暂存文件，将所有文件显示为重复，但char大小写不是问题 [英] git fails to stage files, show all files as duplicate but the char casing is not an issue

问题描述

我在这里阅读过有关类似问题的每一篇文章，但没有一个与我的相同.

就我而言，我对文件之一进行了一个简单的衬纸更改，并想提交更改，但是注意到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，它是具有重复项的一个提交，它是在将远程更改最后一次拉入我的本地分支之后开始显示的.提交B，C，...是提交A之前的提交:

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

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

解决方案

您必须检查问题是否仍然存在于Git 2.22.1(2019年第三季度)/Git 2.25(2020年第一季度)中，如未正确写回磁盘索引文件(在Mac，Linux或Windows上)

请参见提交b5a8169 ， Johannes Schindelin(dscho).
^{(由 Junio C Hamano-gitster-在 t7519的四个状态没有检测到未报告 修改"测试用例偶尔会失败(而且，奇怪的是， 在Windows上很多).}

原因是这些测试用例故意使用了以下副作用: git status如果检测到任何更新，则重写索引:它们 首先清理工作树，并运行git status来更新索引 将输出显示给随意的读者，然后使工作树变脏 再次，如果运行模拟程序，则预计不会报告任何更改 fsmonitor钩子.

此策略的问题在于索引是在 在干净的工作树上说git status，原因是错误:不是 因为索引被标记为已更改(不是)，但是因为 记录的mtimes与索引自身的mtime保持一致.

由于Windows上的mtime粒度为100纳秒(请参见例如 https://docs.microsoft.com/en-us/Windows/桌面/SysInfo/文件时间)， 文件的mtimes通常对于带有索引的 not 不够敏感，因此 git status调用当前并不总是更新索引 (包括fsmonitor扩展名)，导致测试用例失败.

明显的解决方法:如果我们更改 any 索引条目的CE_FSMONITOR_VALID 标记，我们还应该将索引标记为已更改.
这将导致将索引写在git status上，其中包括一个更新的fsmonitor扩展名.

旁注:即使读者可能认为 https://unix.stackexchange.com/questions/11599#comment762968_11599 ;它 非常很难找到有关此类信息的任何适当信息来源 ext4问题)，其准确性似乎取决于许多因素，但是 安全地比NTFS的100纳秒粒度差(再次，它是 非常很难找到关于此的远程权威 问题).因此，似乎隐藏了该错误的活动指数条件 在Linux上，此补丁程序修复的可能性比在 视窗.但不是不可能；-)

---

在Git 2.25(2020年第一季度)中，fsmonitor更加强大，并且删除了不应该触发的错误BUG().

请参见提交61eea52 (2019年11月13日)由 Junio C Hamano-gitster-在 fsmonitor :请勿将位图大小与拆分索引大小进行比较

^{报告人:Utsav Shah
帮助人:凯文·威尔福德
帮助人:威廉·贝克(William Baker)}

3444ec2e ("fsmonitor:不将位图填充到被删除"，2019年10月11日，Git v2.24.0-rc1-合并第11 批中列出的)中添加了一些健全性检查，以确保fsmonitor位图中的位位置不会超出索引的末尾.

由于位图中的每个位对应于索引中的路径，因此大多数时候这是正确的检查.

除了处于拆分索引模式并查看要在基本索引上被合并但尚未实际合并基本索引之前(即在read_和write_fsmonitor_extension()中)覆盖的增量索引的情况之外.

在这些代码路径中，split/delta索引中的条目通常是整个路径集中的一小部分(否则我们为什么要使用split-index?)，因此fsmonitor所使用的位图几乎是总是大于部分索引中的条目数，并且不正确的比较将触发BUG().

I have read every single post on here about similar issues but none of them are same as mine.

In my case, I did simple one liner change to one of my file and wanted to commit my changes but noticed that commit -am "" did not add/commited the file.

After issuing git ls-files --stage, I see probably all files in my project showing as duplicates. Here is example of one of the files

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

Interestingly, some of the files showing ad duplicates are not modified by me at all, some are but nevertheless, they show as duplicate and as you can see below, the casing is not the issue like in other SO posts on here.

UPDATE

While this does not resolve my issue described above, it helped me to use git reset --hard HEAD~1 which resets HEAD pointer to 2nd last commit which is the commit that worked. I use --hard above to discard last commit since it caused the issue above for me. If you need to keep these changes, using --soft instead will reset HEAD to your commit before last commit and add changes in last commit to staging area.

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

Above commands reset HEAD pointer 1, 2, 3, ... commits before last commit and discard any changes after. Use --soft instead of --hard if you dont want to discard these changes in which case these changes will be staged for you.

This is the situation I had. Below, last commit is commit A which is the one with the duplicates that started showing up after last pull of remote changes into my local branch. Commits B, C, ... are commits before commit A:

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

, now my last commit is commit B which does not have the duplicates. I can now try to merge again and see if I will have the same issue as I had with commit A. As I mentioned this does not solve the issue but at least allows me to try to recreate it or continue my work and deal with the merge later.

解决方案

You will have to check if the issue persists in Git 2.22.1 (Q3 2019)/ Git 2.25 (Q1 2020), as The data collected by fsmonitor was not properly written back to the on-disk index file (on Mac, Linux or Windows)

See commit b5a8169, commit d4c0a3a (24 May 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 10432cc, 25 Jul 2019)}

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://docs.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 ;-)

---

With Git 2.25 (Q1 2020), fsmonitor is more robust, and removes an incorrect BUG() that should not trigger.

See commit 61eea52 (13 Nov 2019) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit aec3b2e, 01 Dec 2019)}

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().

这篇关于git无法暂存文件，将所有文件显示为重复，但char大小写不是问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！