Cherry pick indicates that the -m option was set error

Question

I have two main masters and development

I need to get some commit id from the development branch in the main branch, so I am doing this with cherry capture, but it shows me some error.

$> git cherry-pick cf0d52b error: Commit cf0d52b900f990300c3aa17936ddbae1476d461a is a merge but no -m option was given. fatal: cherry-pick failed 

I do not get this error, why this error occurs and how I can get rid of it.

Answer 1

You are trying to merge cherry-pick . The merger comes from several parents. You must provide the parent id for the merge.

You must specify any of the following:

-m parent-number / --mainline parent-number

Usually you cannot use cherry merge because you do not know which side of the merger should be considered the main one.

This parameter indicates the parent number (starting from 1) of the main line and allows the cherry plant to reproduce the change relative to the specified parent.

---

How to find out what commit parents are?

Use the git show command to view the commit parents, and then you can choose the parent index or SHA-1

Answer 2

Just like a mistake. You are trying to choose a merge commit, so you tell git with which parent it should produce diff, which is then applied to the target.

Answer 3

This option specifies the parent number (starting at 1)

Prior to Git 2.13 (Q2 2017) this number could be 0! (which is wrong)

See commit b16a991 (March 15, 2017) by Jeff King ( peff ) .
^{(merged Junio ​​C Hamano - gitster - in commit 9c96637 , March 17, 2017}

cherry-pick : detect dummy arguments --mainline

Cherry pick and return OPT_INTEGER() use OPT_INTEGER() to parse --mainline . The stock analyzer is smart enough to reject non-numeric nonsense, but it does not know that the count of parent frames starts at 1.

Worse, the value "0" is indistinguishable from an unspecified case, so a user who believes that the calculation is based on 0 will receive a confused message:

 $ git cherry-pick -m 0 $merge error: commit ... is a merge but no -m option was given. 

The correct diagnosis is that " -m 0 " does not apply to the first parent element (" -m 1 " does).