Junio C Hamano <gitster@xxxxxxxxx> writes:
> "Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
>> 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.
