Re: [PATCH 3/3] wt-status: suggest 'git rebase --continue' to conclude 'merge' instruction

> On Thu, 3 Apr 2025, phillip.wood123@gmail.com wrote:
>> On 03/04/2025 13:17, Johannes Schindelin wrote:
>>> 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`?
> 
> [Fixed totally garbled formatting that pretended that the first half of
> this sentence was written by me, the second half by you:]

>> `git cherry-pick` retains authorship by writing CHERRY_PICK_HEAD which
>> `git commit` uses to look up the commit message and authorship.
> 
> And why can we not teach `git commit` to use the author information
> recorded in `.git/rebase-merge/author-script`, too, and teach `git reset
> --hard` to delete it?

>> 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`.
> 
> The reason is probably more that you can mix `git rebase` and `git
> cherry-pick` (why does this common operation have such a long name,
> again?). I actually do this quite often, I frequently even have something
> like this in my rebase scripts:
> 
> 	exec git cherry-pick ..upstream/seen^{xx/something-something}^2
> 
>> 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.
> 
> Right. But it can recapitulate cherry-pick's strategy in spirit. After
> all, `git commit` had to be taught about an interrupted `git cherry-pick`
> so that it _could_ pick up the necessary information and use that.
> Likewise, `git commit` could be taught about an interrupted `git rebase`
> and similarly pick up the author information from what `git rebase`
> recorded.
> 
>> 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.
> 
> Even I, the inventor of `git rebase -i`, have run afoul of this authorship
> resetting on more than a dozen occasions.
> 
> This is proof enough for me that Git is unnecessarily confusing (no big
> revelation there, right? Git earned that reputation very effortlessly, not
> only in this particular scenario).