在我的例子中，我对我的一个文件做了简单的一行更改，并希望提交我的更改，但注意到commit -am“”没有添加/提交文件。
在发出git ls-files --stage之后，我可能会看到项目中的所有文件都显示为重复文件。以下是其中一个文件的示例
100644 6314bd3f89d1b794c6d8c0fb9bb4aa492e2d510a 0 SquirrelFoH/Squirrel.FoH.ViewModels/UserLoginViewModel.cs
100644 6314bd3f89d1b794c6d8c0fb9bb4aa492e2d510a 0 SquirrelFoH/Squirrel.FoH.ViewModels/UserLoginViewModel.cs有趣的是，一些显示广告重复的文件根本没有被我修改，有些是，但尽管如此，它们显示为重复，正如你在下面看到的， shell 不是像其他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相同的问题。正如我提到的，这并没有解决问题，但至少允许我尝试重新创建它或继续我的工作，并处理合并后。
1条答案
按热度按时间toe950271#
你需要检查这个问题是否在Git 2中仍然存在。22.1（Q3 2019）/ Git 2.25（2020年第1季度），因为
fsmonitor收集的数据未正确写回磁盘索引文件（在Mac、Linux或Windows上）参见commit b5a8169，commit d4c0a3a（2019年5月24日）by Johannes Schindelin (
dscho)。（由Junio C Hamano --
gitster--合并于commit 10432cc，2019年7月25日）mark_fsmonitor_valid()：如果需要，将索引标记为已更改如果没有这个bug修复，t7519's four "status doesn't detect unreported modifications" test cases偶尔会失败（而且，奇怪的是，在Windows上 * 更频繁 ）。
原因是这些测试用例有意使用
git status的副作用来重写索引，如果检测到任何更新：他们首先清理工作树，运行git status来更新索引，并将输出显示给临时读者，然后再次使工作树变脏，并且如果使用模拟的fsmonitor钩子运行，则不期望报告任何更改。这种策略的问题是，在
git status期间，由于 * 错误 * 的原因，在clean worktree上写入了索引：这并不是因为索引被标记为已更改（它没有），而是因为记录的mtimes与索引自己的mtime是活泼的。由于Windows上的
mtime粒度为100纳秒（参见e.例如https://learn.microsoft.com/en-us/windows/desktop/SysInfo/file-times），文件的mtimes经常是足够的 not racy with the index '，所以git status调用当前并不总是更新索引（包括fsmonitor扩展名），导致测试用例失败。显而易见的解决办法：如果我们更改 any index条目的
CE_FSMONITOR_VALID标志，我们也应该将索引标记为已更改。这将导致索引写入
git status， 包括 * 更新的fsmonitor扩展。旁注：即使读者可能认为t7519问题在Linux上应该更加普遍，因为ext4文件系统（似乎每个Linux发行版都使用）以纳秒精度存储mtimes。然而，ext4使用
current_kernel_time()（参见https：//unix.stackexchange.11599#comment762968_11599;很难找到关于ext4问题的任何适当的信息来源），其准确性似乎取决于许多因素，但安全地比NTFS的100纳秒粒度更差（同样，很难找到关于这个问题的任何权威性的东西）。因此，似乎隐藏这个补丁修复的bug的活泼索引条件在Linux上比在Windows上更有可能。但并非不可能;- ）
在Git 2.25（2020年第一季度）中，fsmonitor更加健壮，并删除了不应该触发的错误BUG（）。
请参阅commit 61eea52（2019年11月13日）Junio C Hamano (
gitster)。（由Junio C Hamano --
gitster--合并于commit aec3b2e，2019年12月1日）fsmonitor：不将位图大小与拆分索引的大小进行比较报告人：乌察夫沙
导演：Kevin Willford
帮助人：William Baker
3444ec2e（“
fsmonitor：不要用要删除的条目填充位图”，2019-10-11，Git v2.24.0-rc 1--merge列出在batch #11中）添加了一些健全性检查，以确保fsmonitor位图中的位位置不会超出索引的末尾。由于位图中的每个位对应于索引中的路径，因此大多数情况下这是正确的检查。
除了当我们在拆分索引模式中，并且在基本索引实际合并之前，即在read_ and
write_fsmonitor_extension()中，查看要覆盖在基本索引上的增量索引的情况。在这些代码路径中，split/delta索引中的条目通常是整个路径集合的一个小子集（否则为什么我们要使用split-index？），因此
fsmonitor使用的位图几乎总是大于部分索引中的条目数，错误的比较将触发BUG（）。索引文件在某些情况下可能会损坏，当使用拆分索引功能时，特别是与fsmonitor一起使用，这已经在Git 2中得到了纠正。41（2023年第二季度）。
参见commit 061dd72、commit be6b65b、commit 3b7a447、commit 3704fed（2023年3月26日）by Johannes Schindelin (
dscho)。（由Junio C Hamano --
gitster--合并于commit f315a8b，2023年4月4日）fsmonitor：避免覆盖cache_changed位作者：Jeff Hostetler
签字人：约翰内斯·申德林
自e636a7b（“
read-cache：具体说明索引的哪一部分发生了变化”，2014-06-13，Git v2.1.0-rc 0--merge列在batch #8中），范例cache_changed = 1不再流行，它变成了一个位字段。这是很重要的，因为一些位具有特定的含义，并且不应该不小心地取消设置。例如
SPLIT_INDEX_ORDERED。但是，b5a8169（
mark_fsmonitor_valid()：如果需要，将索引标记为已更改，2019-05-24，Git v2。23.0-rc 0--merge列于batch #2）(mark_fsmonitor_valid()中：如果需要，将索引标记为已更改，2019-05-24）确实使用了cache_changed属性，就好像它是布尔值而不是位字段一样。这不仅会在通过FSMonitor将索引条目标记为有效时覆盖
SPLIT_INDEX_ORDERED位，而且更糟糕的是：它将设置SOMETHING_OTHER位（其值为1）。这意味着当请求分割索引时，Git会不必要地强制写出完整索引。
让我们使用专门用于指示FSMonitor触发的更改的位，从而允许拆分索引特性按设计工作。