Hi Phillip, On Wed, 2 Apr 2025, phillip.wood123@xxxxxxxxx wrote: > On 01/04/2025 17:22, Johannes Schindelin wrote: > > > On Fri, 28 Mar 2025, Philippe Blain via GitGitGadget wrote: > > > > > From: Philippe Blain <levraiphilippeblain@xxxxxxxxx> > > > > > > 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
