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

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Johannes

On 04/04/2025 12:41, Johannes Schindelin wrote:
> 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:]

Sorry I'm not sure what happened there

>> `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?

If the user passes "--committer-date-is-author-date" then we write the 
author-script when stopping for an unconflicted edit command. However if 
the user runs "git commit" rather than "git commit --amend" we do not 
want to use that script because they are creating a new commit. That 
means that "git commit" cannot simply use the author-script if it 
exists. I expect we could read all of the rebase state to figure out 
what to do but I think it is a much simpler UI to say that the user 
should run "git rebase --continue" unless the user is creating a new 
commit. Otherwise in a world where "git commit" knows about the author 
script the user has to figure out whether or not they need to pass 
"--amend" when running "git commit". If they're committing a conflict 
resolution for a normal pick they should run "git commit". However if 
they are committing a conflict resolution for a fixup then they need to 
add "--amend". If "git commit" starts deciding whether to amend or not 
to avoid the user having to remember that is even more confusing because 
it is behaving differently during a rebase compared to any other time.

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

I think it's confusing because "git commit" tries to do too much and 
that it was a mistake to allow merge conflicts to be committed by "git 
commit" rather than "git <cmd> --continue". I believe the reason "git 
commit" allows conflict resolutions to be committed is historical and 
that "git merge --continue" was a later addition. Originally "git 
commit" was the only way to conclude a conflicted merge. Arguably that's 
not too bad for a merge or a single cherry-pick but I'd argue it would 
be much less confusing if "git commit" refused to run when it looked 
like the user was committing a conflict resolution and told them to run 
"git <cmd> --continue" instead.

> I'd rather like this usability problem to be fixed, even if it is a pain.
> If the pain stems from the way the source code is organized, well, then
> maybe this hints at the need to clean up a little?
The sequencer could certainly use a clean up but I fear it would be a 
huge time sink for both the patch author and the reviewer.

Best Wishes

Phillip