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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 10, 2020, 21:04 UTC
Message-ID: <xmqqlfn3hx1v.fsf@gitster.c.googlers.com>
In-Reply-To: <xmqqpncfhy3g.fsf@gitster.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 17 quoted lines

> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> 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.