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 2, 2025, 13:09 UTC
Message-ID: <a81dbb21-b50b-4358-b2d4-7f804b66bcbc@gmail.com>
In-Reply-To: <0bd7e0c1-fe73-9e16-0737-d6b175a60dd3@gmx.de>

Hi Johannes

On 01/04/2025 17:22, Johannes Schindelin wrote:

Show 16 quoted lines

> Hi Philippe,
> 
> 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.

Best Wishes

Phillip

  (Why is that so? Can

> we really not use the same trick with `merge`s?)
> 
> Ciao,
> Johannes