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

From: Sami Boukortt <sami@boukortt.com>
Date: Apr 7, 2020, 17:27 UTC
Message-ID: <CAAb+AL-95RKhTghJX4uLxiM3dqZW6U914XBXaLcwK+gC_FezWw@mail.gmail.com>
In-Reply-To: <CABPp-BGFinonZJb2u_0-fX3y_UyJ1dY+O40oN0WAzZht0ddJ4w@mail.gmail.com>

Thank you for the very prompt response.

Le mar. 7 avr. 2020 à 18:54, Elijah Newren <newren@gmail.com> a écrit :

Show 17 quoted lines

>
> 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