From: Phillip Wood Date: Fri, 09 Feb 2024 16:24:10 GMT Subject: Re: Interactive rebase: using "pick" for merge commits Message-ID: In-Reply-To: <424f2e08-a2ad-4bb2-8a6b-136c426dc127@haller-berlin.de> Hi Stefan On 09/02/2024 15:52, Stefan Haller wrote: > When I do an interactive rebase, and manually enter a "pick" with the > commit hash of a merge commit, I get the following confusing error message: > > error: commit fa1afe1 is a merge but no -m option was given. > hint: Could not execute the todo command > hint: > hint: pick fa1afe1 some subject > hint: > hint: It has been rescheduled; [rest of message snipped] > > This error message makes it sound like I could somehow add "-m1" after > the "pick" to make it work (which is actually what I would like to be > able to do). I had to go read the source code to find out that that's > not the case, and the error message only comes from the fact that the > code is shared with the cherry-pick and revert commands, which do have > the -m option. Oh, that's unfortunate - we should really reject the todo list when we parse it at the start of the rebase if it is going to try and "pick" a merge. > Is it crazy to want pick to work like this? Should it be supported? It causes problems trying to maintain the topology. In the past there was a "--preserve-merges" option that allowed one to "pick" merges but it broke if the user edited the todo list. The "--rebase-merges" option was introduced with the "label", "reset" and "merge" todo list instructions to allow the user to control the topology. Best Wishes Phillip