1

使用 git 2.25.1 使用 git sparse-checkout init/set 来设置 sparsecheckout。

现在我处于需要中止合并的情况。

试过：

git merge --abort

条目“QStreams_xxx/infra/QPrism/Qpvc/gradle_pvc/gradle_pvc.iml”不是最新的。无法更新稀疏结帐。致命：无法将索引文件重置为修订版“HEAD”

试过：

git reset --hard

相同的错误信息。

试图禁用稀疏结帐

git sparse-checkout disable

错误：

错误：无法禁用稀疏签出：您有未暂存的更改。 错误：此外，您的索引包含未提交的更改。

在这有什么办法吗？

谢谢波阿斯

4

2 回答 2

0

不确定这是否是最好的流程，但至少它让我有一些出路......

git read-tree --restore HEAD
#now usual cleanup
git restore .
git clean -xdf
于 2020-03-15T15:14:56.027 回答
0

Git 2.34（2021 年第四季度）的合并应该更加健壮：各种合并操作已准备好与稀疏索引有效地工作。

对于新的（和默认的）合并策略 ORT（“表面上递归的双胞胎”，这将是 Git 2.34，2021 年第四季度的默认策略）尤其如此。

请参阅Derrick Stolee ( ) 的提交 516680b、提交 5d9c934、提交 c0b9930、提交 6957636、提交 a338063、提交 ad90da7（2021 年 9 月 8 日）。（由Junio C Hamano 合并 -- --在提交 a16dd13中，2021 年 9 月 20 日）derrickstolee
gitster

merge: 使用 ORT 实现稀疏感知

签字人：Derrick Stolee
审核人：Elijah Newren

允许 ' git merge' ( man )在不扩展稀疏索引的情况下进行操作，至少不会立即进行。
在某些情况下，索引仍会扩展：

  1. 如果合并策略是“递归”的，那么我们在 merge_recursive() 方法的开头启用 command_requires_full_index。我们希望稀疏索引用户也启用“ort”策略。

  2. 使用“ort”策略，如果合并导致文件冲突，那么我们在更新工作树之前扩展索引。遍历工作树的循环替换索引条目并跟踪“ original_cache_nr”，如果索引在操作中间扩展，这可能会变得完全错误。在循环开始之前，这个安全阀很重要。稍后的更改将仅在我们确实在稀疏结帐锥之外存在冲突时才将其重点扩展。

  3. 其他合并策略作为 执行git merge-X subcommand，并且这些策略当前受 'command_requires_full_index' 保护。

需要进行一些测试更新，包括未指定基本分支的错误 ' git checkout -b' ( man ) ，从而导致合并为快进合并。

于 2021-10-10T10:12:24.160 回答