git rebase -i --retain-empty-commit

Question

默认情况下，当您使用git rebase -i时，它会注释掉空提交，我必须取消注释（他们对我有帮助）。 rebase命令是否有一个选项可以防止这种不必要的假设，即我不想保留它们？

Answer 1

好的，这比预期的要容易：

git rebase -i --keep-empty

希望这篇文章能加速其他人谷歌搜索找到答案。

Answer 2

在Git 2.26（2020年第一季度）中，“ git rebase”已学会默认使用合并后端（即驱动“ rebase -i”的机器），同时允许“ --apply” “选项以使用” apply“后端（例如，道德上等同于” format-patch piped to am“）。
（可以将rebase.backend配置变量设置为自定义。）

作为改进的一部分， --keep-empty现在是默认设置！

请参见commit 10cdb9f，commit 2ac0d62，commit 8295ed6，commit 76340c8，commit 980b482，commit c2417d3，commit 6d04ce7，{{3} }，commit 52eb738，commit 8af14f0，commit be50c93，commit befb89c，commit 9a70f3d，commit 93122c9，commit 55d2b6d，commit 8a997ed， commit 7db00f0的commit e98c426，commit d48e5e2（2020年2月15日）和commit a9ae8fd，commit 22a69fd（2020年1月16日）。
^{（由Elijah Newren (newren)在Junio C Hamano -- gitster --中合并，2020年3月2日）}

commit 8c22bd9：将--keep-empty设为默认值

^{签名人：伊利亚·纽伦}

对于开始为空的提交，不同的rebase后端有不同的处理方式（即，相对于其父级没有更改），并且在某些时候添加了--keep-empty选项以允许调整行为。
开始为空的提交的处理实际上与rebase (interactive-backend)（“ git-rebase：使--allow-empty-message为默认值”非常相似，2018-06-27，Git v2.19.0-rc0- -commit b00bf1c9a8dd中列出的merge），指出各种后端的行为通常比设计更多的偶然性。

在该提交中所做的特定更改实际上也非常相关，并且这里的许多逻辑直接适用于此。

除非提供重写标志，否则'git commit'会在创建空提交时出错，这很有意义。

但是，一旦有人确定使用手动替代来创建这样一个提交的情况很少，那么必须采取额外的步骤来保持这种故意的提交是介于烦人和有害之间的。

授予的空提交非常少见，这就是为什么对它们的处理没有得到足够重视的原因，并且人们倾向于顺应现有的（偶然的）行为，并认为是有原因的，导致他们仅添加标志（ --keep-empty），允许他们覆盖错误的默认设置。

修复交互式后端，使--keep-empty为默认值batch #4。

am后端也应该固定为具有--keep-empty语义的开始为空的提交，但除了记录故障的测试用例之外，不包含在此补丁中。

请注意，t3421中有一项测试似乎是写成期望--keep-empty并非默认的正确行为。

此测试是在much like we did with --allow-empty-message中引入的（“添加测试以对空提交进行基础调整”，2013-06-06，Git v1.8.4-rc0-commit 00b8be5a4d38），是着重于基础拓扑的系列文章，其中有一个merge指出了

对于您是否同意测试用例的意图，您的意见尤其感谢。

，然后进入一个很长的示例，说明添加的许多测试中的一项如何对它是否正确提出了若干问题。

因此，我相信该系列中的大多数测试都是关于使用尽可能多的不同标志来测试基础拓扑的，并且并没有试图概括地说明这些标志应如何表现。