Re: [PATCH v2 0/3] rebase -i: mark commits that begin empty in todo editor

Junio C Hamano [off-list ref] writes:

"Elijah Newren via GitGitGadget" [off-list ref] writes:

quoted

I wanted to base this commit on jt/rebase-allow-duplicate, in particular to
add a patch moving his new --[no-]keep-cherry-picks arguments to be close to
the --empty={drop,keep,ask} and --[no-]keep-empty flags, since all three are
related. But unfortunately that series was based on 2.25, and my series
needs to be based on 2.26.

Even though this one might qualify as a regression fix to be based
on an older track, the other one is a new "feature" and is not even
in 'next' yet, so there is no reason why we must keep its base on
maintenance tracks (perhaps its earliest round was first queued when
2.25 was the latest tagged release?)

So I am OK to rebase the other topic to v2.26.0; would that help?  I
already saw there was some entanglement with the other topic in one
of the patches in this series, so...

This is a total tangent, but when I tried to rebase
jt/rebase-allow-duplicate that builds directly on top of v2.25.0 to
a newer base, after resolving conflicts, "commit -a" and "rebase
--continue", somewhere I seem to have mangled the authorship.  It
could entirely be a driver error, or it may be a bug in "rebase",
especially with recent backend change.  I am planning to come back
to it later to figure out if there is such a bug, but I'd need to
recover from the authorship screwup first, so it may take some
time.