Re: [PATCH 3/3] wt-status: suggest 'git rebase --continue' to conclude 'merge' instruction
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Apr 3, 2025, 12:17 UTC
- Message-ID
- <15222e69-9452-fd61-6ffc-8c8de0c68d8a@gmx.de>
- In-Reply-To
- <a81dbb21-b50b-4358-b2d4-7f804b66bcbc@gmail.com>
Hi Phillip,
On Wed, 2 Apr 2025, phillip.wood123@gmail.com wrote:
Show 23 quoted lines
> 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