git rebase -i --retain-empty-commits

With Git 2.26 (Q1 2020), "git rebase" has learned to use the merge backend (i.e. the machinery that drives "rebase -i") by default, while allowing "--apply" option to use the "apply" backend (e.g. the moral equivalent of "format-patch piped to am").
(The rebase.backend configuration variable can be set to customize.)

As part of this improvement, --keep-empty is now the default!

See 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).
^{(Merged by Junio C Hamano -- gitster -- in commit 8c22bd9, 02 Mar 2020)}

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.

and then went into a long example about how one of the many tests added had several questions about whether it was correct.

As such, I believe most the tests in that series were about testing rebase topology with as many different flags as possible and were not trying to state in general how those flags should behave otherwise.

Okay, that was easier than expected:

git rebase -i --keep-empty

Hopefully this post will speed up others Googling to find the answer.