Re: [PATCH 3/3] wt-status: suggest 'git rebase --continue' to conclude 'merge' instruction
- From
- phillip.wood123@gmail.com <phillip.wood123@gmail.com>
- Date
- Apr 3, 2025, 15:08 UTC
- Message-ID
- <08837a1a-b46d-4456-beba-5c889fe9e674@gmail.com>
- In-Reply-To
- <15222e69-9452-fd61-6ffc-8c8de0c68d8a@gmx.de>
Hi Johannes
On 03/04/2025 13:17, Johannes Schindelin wrote:
Show 19 quoted lines
> Hi Phillip, > On Wed, 2 Apr 2025, phillip.wood123@gmail.com 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