3

就我而言，我对我的一个文件进行了简单的一行更改，并想提交我的更改，但注意到 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 相同的问题。正如我所提到的，这并不能解决问题，但至少允许我尝试重新创建它或继续我的工作并处理稍后合并。

4

1 回答 1

0

您必须检查问题是否在 Git 2.22.1（2019 年第三季度）/ Git 2.25（2020 年第一季度）中仍然存在，因为收集的数据fsmonitor未正确写回磁盘索引文件（在 Mac、Linux 或 Windows 上） )

请参阅提交 b5a8169和提交 d4c0a3a（2019 年 5 月 24 日），Johannes Schindelin ( dscho)。
（由Junio C Hamano 合并 -- gitster--在提交 10432cc中，2019 年 7 月 25 日）

mark_fsmonitor_valid()：如果需要，将索引标记为已更改

如果没有此错误修复，t7519 的四个“状态未检测到未报告的修改”测试用例偶尔会失败（而且，奇怪的是， 在 Windows 上更频繁）。

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

这种策略的问题在于，索引是在git statusclean worktree 上写的，原因是错误的：不是因为索引被标记为已更改（不是），而是因为记录mtimes的索引与索引自己的 mtime 无关。

由于mtimeWindows 上的粒度为 100 纳秒（参见例如 https://docs.microsoft.com/en-us/windows/desktop/SysInfo/file-times），mtimes因此文件的索引通常足够不活泼，这样该git status调用当前并不总是更新索引（包括fsmonitor扩展名），从而导致测试用例失败。

显而易见的解决方法：如果我们更改任何索引条目的CE_FSMONITOR_VALID 标志，我们也应该将索引标记为已更改。
这将导致索引被写入git status，包括更新的fsmonitor扩展。

旁注：尽管读者可能认为t7519问题应该在 Linux 上更为普遍，因为 ext4 文件系统（似乎每个 Linux 发行版都使用）以纳秒精度存储 mtime。但是，ext4 使用current_kernel_time()（请参阅 https://unix.stackexchange.com/questions/11599#comment762968_11599；很难找到有关此类ext4问题的任何适当信息来源）其准确性似乎取决于许多因素，但安全性更差比 NTFS 的 100 纳秒粒度（再次，这太 可怕了）很难找到关于这个问题的任何远程权威）。因此，隐藏此补丁修复的错误的活泼索引条件似乎在 Linux 上比在 Windows 上更有可能发生。但并非不可能；-)

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

请参阅Junio C Hamano ( ) 的提交 61eea52（2019 年 11 月 13 日）。（由Junio C Hamano 合并 -- --在提交 aec3b2e中，2019 年 12 月 1 日）gitster
gitster

fsmonitor: 不要将位图大小与拆分索引的大小进行比较

报告人：Utsav Shah
帮助者：Kevin Willford
帮助者：William Baker

3444ec2e（“ fsmonitor：不要用要删除的条目填充位图”，2019 年 10 月 11 日，Git v2.24.0-rc1 -批次 #11中列出的合并）添加了一些健全性检查，以确保位位置在 fsmonitor 中位图不会超出索引的末尾。

由于位图中的每个位都对应于索引中的路径，因此大多数情况下这是正确的检查。

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

在这些代码路径中，拆分/增量索引中的条目通常是整个路径集的一小部分（否则我们为什么要使用拆分索引？），因此使用的位图fsmonitor几乎总是大于部分索引中的条目，并且不正确的比较会触发 BUG()。

于 2019-06-19T22:58:21.923 回答