Junio C Hamano <gitster@xxxxxxxxx> 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.
