I read somewhere that since git 2.26 --keep-empty is by default for git rebase -i. But I can't think of the use case of it. When I do git interactive rebase I always want to remove the empty commit. What is the point of keeping it?

CodePudding user response：

There are a couple of reasons, but they're mostly esoteric.

One thing I do when developing for Git, where I may need to rebase several series on top of one another yet be able to detect them individually, is to place an empty marker commit with the message :BRANCHNAME at the base of the branch. I then can rebase the first series on to the new main branch by referring to its empty commit, rebase the second series onto the first by referencing its empty commit, and so on.

The change in behavior was unintentional. The main backend changed from an am-based backend, which had always removed empty commits, to a merge-based backend, which didn't have that behavior, and so as the backend changed, the behavior changed unintentionally. Note that in virtually every other way, the merge-based backend is better.