Re: New git-rebase backend: no way to drop already-empty commits

[Sami Boukortt <sami@boukortt.com>]

Thank you for the very prompt response.

Le mar. 7 avr. 2020 à 18:54, Elijah Newren <newren@gmail.com> a écrit :
>
> On Tue, Apr 7, 2020 at 9:33 AM Sami Boukortt <sami@boukortt.com> wrote:
> >
> > Hi,
> >
> > Using git 2.26.0, I just tried using `git rebase` to strip empty
> > commits from a branch, but it leaves them as-is, even with
> > `--empty=drop`. With the “apply” backend, it removes them properly. Am
> > I holding it wrong?
> >
> > `git rebase -i` also doesn’t pre-comment them like it used to.
>
> Yes, from the manpage:
>
> """
> […]
> """

D’oh, not sure how I missed this. :) Thanks.

> To remove previously intentional commits, whether empty or not, use -i
> and remove the lines corresponding to the commits you don't want.

Sadly, that is somewhat inconvenient, as those commits are not
actually “intentional” from my viewpoint (though I understand that git
has no way of knowing this), but rather created by another tool
(git-imerge), which means that I have to check each commit
individually and risk mistakes. The old `rebase -i` behavior, where
such commits were automatically commented out, would be an acceptable
compromise, or even a comment added at the end of the commit line (so
that they are still kept if the editor is closed without changing the
rebase list). If there are plans to eventually remove the “apply”
backend, could that workaround be considered?

Alternatively, I could also use `git filter-branch` (with
`--prune-empty`), but apparently, its use is heavily discouraged.

Thanks again,
Sami