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

From: Elijah Newren <newren@gmail.com>
Date: Apr 7, 2020, 18:03 UTC
Message-ID: <CABPp-BE1mDQYcj6nRfS4osn8-E_WdV-Nenn9dQSA+JCr+pjKLQ@mail.gmail.com>
In-Reply-To: <CAAb+AL-95RKhTghJX4uLxiM3dqZW6U914XBXaLcwK+gC_FezWw@mail.gmail.com>

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

Show 31 quoted lines

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

git-imerge creates non-merge commits? Is this in the case when it is acting like rebase? If so, is this possibly a bug in git-imerge (in that it doesn't drop commits which become empty)?

Show 6 quoted lines

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

Automatically commenting them out is bad; that causes frustration for people having to uncomment all the commits they intended to add.

But we could add some kind of option.

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

You could use
   git filter-repo --prune-empty always