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

[Elijah Newren <newren@gmail.com>]

On Tue, Apr 7, 2020 at 11:16 AM Sami Boukortt <sami@boukortt.com> wrote:
>
> Le mar. 7 avr. 2020 à 20:03, Elijah Newren <newren@gmail.com> a écrit :
> >
> > On Tue, Apr 7, 2020 at 10:28 AM Sami Boukortt <sami@boukortt.com> wrote:
> > >
> > > […]
> > >
> > > 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)?
>
> It is indeed with `git imerge rebase`. I don’t know enough about
> git-imerge’s internals to know how easy that would be to fix, but it
> does seem as though that would be the ideal approach.

I don't either; maybe Michael Haggerty (cc'ed) can chime in on this
side of things.

> > > 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.
>
> Instead of automatically commenting them out, how about automatically
> annotating them while leaving them in the rebase list, like so:
>
>     pick 8441f42 Commit A
>     pick e3fcaf8 Commit B  # empty
>     pick af34c53 Commit C

That seems reasonable.  Of course, that would make it specific to -i;
I'm curious if that's good enough or if there are other cases out
there that need more.  We could at least start with this, though.

> > > 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
>
> That does seem like it would work, but wouldn’t it process the entire
> repository (as opposed to filter-branch which can take a list of
> revisions)?

By default, yes it processes the entire repository.  You can pass
revisions to filter-repo with the --refs option.