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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 4, 2025, 11:41 UTC
Message-ID: <c2f93d99-2f4d-ee6d-7087-42320c6df0f2@gmx.de>
In-Reply-To: <08837a1a-b46d-4456-beba-5c889fe9e674@gmail.com>

Hi Phillip,

On Thu, 3 Apr 2025, phillip.wood123@gmail.com wrote:

Show 20 quoted lines

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

Show 7 quoted lines

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

Ciao, Johannes