git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

Previous: phillip.wood123@gmail.comNext: phillip.wood123@gmail.com
Message 13 of 17 in “rebase -r: a bugfix and two status-related improvements”
  1. 0/3 rebase -r: a bugfix and two status-related improvementsPhilippe Blain via GitGitGadget, Mar 28, 2025
  2. 1/3 rebase -r: do create merge commit after empty resolutionPhilippe Blain via GitGitGadget, Mar 28, 2025
  3. Eric SunshineMar 28, 2025
  4. Eric SunshineMar 28, 2025
  5. Johannes SchindelinApr 1, 2025
  6. Phillip WoodMar 31, 2025
  7. 2/3 wt-status: also abbreviate 'merge' and 'fixup -C' lines during rebasePhilippe Blain via GitGitGadget, Mar 28, 2025
  8. Phillip WoodMar 31, 2025
  9. 3/3 wt-status: suggest 'git rebase --continue' to conclude 'merge' instructionPhilippe Blain via GitGitGadget, Mar 28, 2025
  10. Phillip WoodMar 31, 2025
  11. Johannes SchindelinApr 1, 2025
  12. phillip.wood123@gmail.comApr 2, 2025
  13. Johannes SchindelinApr 3, 2025
  14. phillip.wood123@gmail.comApr 3, 2025
  15. Johannes SchindelinApr 4, 2025
  16. Phillip WoodApr 4, 2025
  17. Phillip WoodMar 31, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.