Hi Johannes
On 03/04/2025 13:17, Johannes Schindelin wrote:
Hi Phillip,
On Wed, 2 Apr 2025, phillip.wood123@xxxxxxxxx wrote:
On 01/04/2025 17:22, Johannes Schindelin wrote:
It is unfortunate that we cannot fix this, as `git commit` with an
interrupted `pick` _would_ retain authorship, right?
Unfortunately not. Running "git commit" rather than "git rebase
--continue" to commit a conflict resolution when rebasing always loses
the authorship.
(Why is that so? Can we really not use the same trick with `merge`s?)
Authorship is retained when a `git cherry-pick` (what an unwieldy command
name for _such_ a common operation!) failed with merge conflicts and those
conflicts were resolved and the user then calls `git commit`, though.
Why can this technique not be used in interrupted `pick`/`merge` commands
of `git rebase`?`git cherry-pick` retains authorship by writing CHERRY_PICK_HEAD which
`git commit` uses to look up the commit message and authorship. When
we're rebasing the sequencer removes CHERRY_PICK_HEAD and instead writes
the commit message to MERGE_MSG and the authorship to
.git/rebase-merge/author-script. I think the reason for the different
behavior is to avoid confusing things like `git status`.
CHERRY_PICK_HEAD has been removed when rebasing since it was introduced
in d7e5c0cbfb0 (Introduce CHERRY_PICK_HEAD, 2011-02-19). These days
rebase supports --reset-author-date which means it cannot use the same
mechanism as cherry-pick. Personally I'd much rather we tell people to
use "git rebase --continue" to commit their conflict resolutions as
using "git commit" has never worked if one wanted to preserve authorship
and I think making it work would be a pain and probably fragile as I'm
not sure how we'd ensure "git commit" knew it was committing a conflict
resolution created by "git rebase" rather than one created by some other
commit run while the rebase was stopped or by an exec command.
Best Wishes
Phillip
