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:14 UTC
Message-ID: <xmqqh7xrhwlu.fsf@gitster.c.googlers.com>
In-Reply-To: <xmqqlfn3hx1v.fsf@gitster.c.googlers.com>

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

Show 9 quoted lines

> 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.

I think I know how it happens now.

52e8d1942c662 == jt/rebase-allow-duplicate

Attempting to rebase this on top of the 'master', i.e.

    $ git rebase --onto master 52e8d1942c662^ 52e8d1942c662

results in a merge conflict, but it is easy to resolve in the working tree. Then after "git add -u" to record the resolution in the index

    $ git commit
    $ git rebase --continue

gives me the authorship credit.

Back when the default rebase backend was 'apply', making the above "mistake" was not even possible; "git commit" would have given me an empty log buffer to edit, without pre-filling anything, to help me realize that I shouldn't commit.

With the sequencer backend, however, the above procedure happily records the commit under the author's name, it seems.

I am not sure if that is a bug.  I am inclined to say so.