git rebase -i --retain-empty-commits

Question

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

Answer 1

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

git rebase -i --keep-empty

希望这个 post 能加快其他人通过谷歌搜索找到答案的速度。

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, commit 52eb738, commit 8af14f0, commit be50c93, commit befb89c, commit 9a70f3d, commit 93122c9, commit 55d2b6d, commit 8a997ed, commit 7db00f0, commit e98c426, commit d48e5e2 (15 Feb 2020), and commit a9ae8fd, commit 22a69fd (16 Jan 2020) by Elijah Newren (newren)。
^{（由 Junio C Hamano -- gitster -- in commit 8c22bd9 合并，2020 年 3 月 2 日）}

rebase (interactive-backend): make --keep-empty the default

^{Signed-off-by: Elijah Newren}

Different rebase backends have different treatment for commits which start empty (i.e. have no changes relative to their parent), and the --keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to commit b00bf1c9a8dd ("git-rebase: make --allow-empty-message the default", 2018-06-27, Git v2.19.0-rc0 -- merge listed in batch #4), which pointed out that the behavior for various backends is often more happenstance than design.

The specific change made in that commit is actually quite relevant as well and much of the logic there directly applies here.

It makes a lot of sense in 'git commit' to error out on the creation of empty commits, unless an override flag is provided.

However, once someone determines that there is a rare case that merits using the manual override to create such a commit, it is somewhere between annoying and harmful to have to take extra steps to keep such intentional commits around.

Granted, empty commits are quite rare, which is why handling of them doesn't get considered much and folks tend to defer to existing (accidental) behavior and assume there was a reason for it, leading them to just add flags (--keep-empty in this case) that allow them to override the bad defaults.

Fix the interactive backend so that --keep-empty is the default, much like we did with --allow-empty-message.

The am backend should also be fixed to have --keep-empty semantics for commits that start empty, but that is not included in this patch other than a testcase documenting the failure.

Note that there was one test in t3421 which appears to have been written expecting --keep-empty to not be the default as correct behavior.

This test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of empty commits", 2013-06-06, Git v1.8.4-rc0 -- merge), which was part of a series focusing on rebase topology and which had an interesting original cover letter which noted

Your input especially appreciated on whether you agree with the intent of the test cases.

然后进入一个很长的例子，关于添加的许多测试中的一个如何有几个关于它是否正确的问题。

因此，我相信该系列中的大多数测试都是关于使用尽可能多的不同标志测试变基拓扑，而不是试图概括说明这些标志在其他情况下应该如何表现。