Error when cherry-picking a merge commit

[guban]

Describe the bug Cherry-picking a merge commit results in error Rebasing (1/1)error: commit ... is a merge but no -m option was given.

To Reproduce

Try cherry-picking any merge commit, or use this script to create a test git repo with a merge commit that is ready to be cherry-picked:

@echo off

git init

echo v1 > a.txt
git add a.txt
git commit -m v1

:: We will cherry-pick our merge commit to branch "release".
git branch release

:: Add the "work" branch with a couple of commits.
git checkout -b work
echo v2 > a.txt
git add a.txt
git commit -m work2
echo v3 > a.txt
git add a.txt
git commit -m work3

:: Merge "work" into "main". Use "--no-ff" to force creating a new merge commit.
git checkout main
git merge --no-ff work

:: Switch to the "release" branch.
git checkout release

echo Now, open lazygit and cherry-pick the merge commit from the "main" branch to "release" branch.

Actual behavior: lazygit shows an error message Rebasing (1/1)error: commit ... is a merge but no -m option was given.

Expected behavior The merge commit is expected to be cherry-picked without any errors.

Desktop (please complete the following information):

• OS: Windows 10
• Lazygit Version v0.28.2

[nanvenomous]

In trying to reproduce this I noticed that running git cherry-pick "merge_hash" on the release branch at the end of the repro script seems to also fail with:

error: commit "merge_hash" is a merge but no -m option was given.
fatal: cherry-pick failed

However it doesn't start a rebase. Should the expected behavior be revised?

[paulwyszynski]

Same problem for merge commits. What's best practice here?

[stefanhaller]

It's a bit tricky to solve, lazygit would have to ask you at copy time which parent you want, and then remember that and use the information when pasting. Well, or simply assume that you mean -m1 since that should be by far the most common case (I guess).

Until we have a solution for this, one workaround is to press enter on the commit you want to cherry-pick, hit a to stage the whole commit into a custom patch, and then press <c-p> a to apply the patch. You just have to commit it yourself then.

[CranewarePlc]

Thanks for the suggested work around.

We use DevOps Azure, and cherry-picking almost invariably is done from a merge-commit when we hotfix. -m1 would work just fine.

Would this not be worth adding to Lazygit - maybe with some confirmation at paste-time to let you know what you are about to do ?

[stefanhaller]

OK, what I wrote above about adding -m1 is nonsense. I was fooled by git's bogus error message (which is a git bug, see here) to think that it's possible to add -m1 after a "pick" entry in a .git-rebase-todo file and make it work this way. That's not possible, git doesn't support this.

So as long as we are implementing copy/paste of commits in terms of an interactive rebase, there's no way to support pasting merge commits, and we should at least give a better error message about that; see #3316.

Here's a possible way to allow cherry-picking merge commits: #3317, but it's a lot of work, and I'm not sure the added complexity is worth it.

[CranewarePlc]

Thank you very much for you feedback. I think I understand the complexities you are referring to. The workaround that you suggested works well for me, and having used it a few times already, I find the flow quite natural.

Can I please thank all of you who work on Lazygit. I've been through a fair few git-tools so far. Lazygit is very pleasant and productive to use, as far as I'm concerned. I'm sticking with it.