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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Phillip,

On Wed, 2 Apr 2025, phillip.wood123@gmail.com wrote:

> On 01/04/2025 17:22, Johannes Schindelin wrote:
>
> > On Fri, 28 Mar 2025, Philippe Blain via GitGitGadget wrote:
> >
> > > From: Philippe Blain <levraiphilippeblain@gmail.com>
> > >
> > > Since 982288e9bd (status: rebase and merge can be in progress at the
> > > same time, 2018-11-12), when a merge is in progress as part of a
> > > 'git rebase -r' operation, 'wt_longstatus_print_state' shows
> > > information about the in-progress rebase (via
> > > show_rebase_information), and then calls 'show_merge_in_progress' to
> > > help the user conclude the merge. This function suggests using 'git
> > > commit' to do so, but this throws away the authorship information
> > > from the original merge, which is not ideal.
> >
> > 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`?

Ciao,
Johannes