Re: Interactive rebase: using "pick" for merge commits

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Feb 9, 2024, 16:24 UTC
Message-ID: <ad561600-faf6-4d3c-80b2-34b3d1a1b99e@gmail.com>
In-Reply-To: <424f2e08-a2ad-4bb2-8a6b-136c426dc127@haller-berlin.de>

Hi Stefan

On 09/02/2024 15:52, Stefan Haller wrote:

Show 16 quoted lines

> 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