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

From: Elijah Newren <newren@gmail.com>
Date: Apr 7, 2020, 16:53 UTC
Message-ID: <CABPp-BGFinonZJb2u_0-fX3y_UyJ1dY+O40oN0WAzZht0ddJ4w@mail.gmail.com>
In-Reply-To: <CAAb+AL8+c6knrQnoi7YOjyM+Wc8-rws-JXVufBc=PciAvPPFJQ@mail.gmail.com>

On Tue, Apr 7, 2020 at 9:33 AM Sami Boukortt <sami@boukortt.com> wrote:

Show 9 quoted lines

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

"""
--empty={drop,keep,ask}::
        How to handle commits that are not empty to start and are not
        clean cherry-picks of any upstream commit, but which become
        empty after rebasing (because they contain a subset of already
        upstream changes).  With drop (the default), commits that
        become empty are dropped....
"""

and

""" Empty commits ~~~~~~~~~~~~~

The apply backend unfortunately drops intentionally empty commits, i.e. commits that started empty, though these are rare in practice. It also drops commits that become empty and has no option for controlling this behavior.

The merge backend keeps intentionally empty commits. Similar to the apply backend, by default the merge backend drops commits that become empty unless -i/--interactive is specified (in which case it stops and asks the user what to do). The merge backend also has an --empty={drop,keep,ask} option for changing the behavior of handling commits that become empty. """

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

Hope that helps, Elijah