On Tue, Apr 7, 2020 at 11:16 AM Sami Boukortt <sami@xxxxxxxxxxxx> wrote: > > Le mar. 7 avr. 2020 à 20:03, Elijah Newren <newren@xxxxxxxxx> a écrit : > > > > On Tue, Apr 7, 2020 at 10:28 AM Sami Boukortt <sami@xxxxxxxxxxxx> 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.
