git rebase因命令的未知退出代码(128)而失败:git-merge-recursive

Question

考虑以下场景: - 2500的上游存储库存储在SVN中 - git用户A将存储库导入git并提交1个补丁 - git用户B将存储库导入git并提交1个补丁 - git用户A想要合并补丁来自git用户B.

在这种情况下,如果用户A使用git merge,那么git历史将被公共svn提交污染(即代替2502提交,历史将包含2501 + 2501 = 5002提交!)

如果用户A使用git rebase,则git历史记录将是正确的(2502提交).这在这个简单的场景中工作得很好,但是如果用户A和用户B每次都没有1次提交,那么就会出现奇怪的复杂情况:git rebase -Xours失败并显示以下消息:

First, rewinding head to replay your work on top of it...
fatal: Could not parse object '98d7cd83de321e737b22240752cd178622d29406^'
Unknown exit code (128) from command: git-merge-recursive 98d7cd83de321e737b22240752cd178622d29406^ -- HEAD 98d7cd83de321e737b22240752cd178622d29406

您可以使用以下github存储库重现此问题:

git clone https://github.com/opentk/opentk
cd opentk
git remote add mono https://github.com/mono/opentk
git fetch mono
git checkout -b integrate
git rebase -Xours mono/rodo-consolidate-opentk

有谁知道为什么会这样？有任何想法如何解决这个问题？

Answer 1

似乎这是一个很少需要探索的问题.我只是偶然发现了这个问题,并且正如本电子邮件中所建议的那样,问题实际上似乎是因为您尝试使用递归策略来进行没有父项的提交(例如,另一个存储库的主分支).

在我的场景中,我加入了两个git存储库,在另一个的master中重新定义了一个git存储库.在你的情况下,转换和合并svn repos,所以我想这几乎是相同的情况.

在我的场景中,我再次使用strategy = recursive和strategy-option = renormalize来忽略恼人的行结尾冲突.它工作得很好,虽然在给定时间我不得不在历史中间发出一个额外的提交,只是为了从提交的文件中丢弃行结尾(在你提交它们之前保持'修改').

这是我克服这个问题的方法:

1. git rebase <branch> --strategy=recursive --strategy-option=ours

First, rewinding head to replay your work on top of it...
fatal: Could not parse object '67fceed5a80ff78ac6f9a437620323131c88cd51^'
Unknown exit code (128) from command: git-merge-recursive 67fceed5a80ff78ac6f9a437620323131c88cd51^ -- HEAD 67fceed5a80ff78ac6f9a437620323131c88cd51

2. git cherry-pick 67fceed5a80ff78ac6f9a437620323131c88cd51 (注意,它是错误消息中显示的哈希!)

3. 解决冲突(如果有的话)

4. git rebase --continue

从第二次提交开始,递归策略将起作用,因为它们都有父级(您刚刚选择的那个).

你会有一些冲突和一些需要提交来偶尔标准化代码,但你将不再被许多无用的行结束冲突所困扰,这些冲突只会混淆并在合并代码中产生错误.

我认为这是一个错误,因为递归策略可能只假设没有父,一个'空'提交/工作树应该用作比较的基础(因此提交中的所有内容都是实际的添加而没有修改).

Answer 2

我对这个错误也有类似的问题，我放弃了rebase，而是cherry-pick选择了更改，并且效果很好。