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

[Junio C Hamano <gitster@pobox.com>]

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

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