Git cherry-pick failed to pick the right changes

Question

Note: It was a mistake from my side. I cherry-picked the parent hash. Please see the update section.
Original Question:
I have a file vmu_hw_test in a branch "test_imu" which has a change similar to seen below

if( g_imu_spi.readFromFifo() == 0)
{
    //Find local maxima and minima event
    g_imu_spi.compute_event();
    //compute the euler
    g_imu_spi.compute_euler();
    //From the average values compute the max
    //g_imu_spi.compute_Max();
    g_imu_spi.compute_Max(buffer);
}

The if statement and the removal of comment were introduced on this commit.
And master branch had

//Find local maxima and minima event
g_imu_spi.compute_event();
//compute the euler
g_imu_spi.compute_euler();
//From the average values compute the max
g_imu_spi.compute_Max(buffer);

Question
1. As I've read cherry-pick takes a single commit change and applies it. Is there a problem if the branches are different (in commit history)
2. A Microsoft document says not to cherry pick. Is it a bad practice to cherry pick?
3. Why would have cherry pick failed? (Update: It did not.)

Git Diff
For the latest commit on test_imu.c

diff --git a/Src/vmu_hw_test.c b/Src/vmu_hw_test.c
index 14b0a67..1954d64 100644
--- a/Src/vmu_hw_test.c
+++ b/Src/vmu_hw_test.c
@@ -2694,14 +2694,16 @@ unsigned short  IMU_sendData(void)
                }
            }
    //Regular run
-                               g_imu_spi.readFromFifo();
-                               //Find local maxima and minima event
-                               g_imu_spi.compute_event();
-                               //compute the euler
-                               g_imu_spi.compute_euler();
-                               //From the average values compute the max
-//                             g_imu_spi.compute_Max();
-                               g_imu_spi.compute_Max(buffer);
+                               if( g_imu_spi.readFromFifo() == 0)
+                               {
+                                   //Find local maxima and minima event
+                                   g_imu_spi.compute_event();
+                                   //compute the euler
+                                   g_imu_spi.compute_euler();
+                                   //From the average values compute the max
+                                   g_imu_spi.compute_Max(buffer);
+                               }
+

Update
Git cherry-pick did not fail. I tried looking into the diffs as suggested by torek and found that the diffs do state that a cherry pick should have included the if statement.
Here's the git diff --find-renames <hash-of-B> <hash-of-C> (please refer to torek's answer)

unsigned short  IMU_sendData(void)    
{
@@ -2703,7 +2731,6 @@ unsigned short  IMU_sendData(void)
                                //compute the euler
                                g_imu_spi.compute_euler();
                                //From the average values compute the max
-//                             g_imu_spi.compute_Max();
                                g_imu_spi.compute_Max(buffer);

                    //Low pass filter for each axis
@@ -2741,28 +2768,8 @@ unsigned short  IMU_sendData(void)
        }
    }

And the git diff --find-renames <hash-of-B> <hash-of-A> is already provided in the Git Diff section. From this we can see that the if statement should be cherry picked.

What went wrong was that I cherry picked the wrong hash (I picked the parent hash).

Answer 1

git cherry-pick works by merging—but the inputs to the merge are a bit unusual.

Specifically, with a normal, typical merge, we start with the commit graph, from which we find what you have done on your branch, vs what someone else has done on their branch:

             A--B--C   <-- you (HEAD)
            /
...--o--o--*
            \
             D--E--F   <-- them

Each round node, or *, or uppercase letter, represents a commit (the actual commits have commit hash IDs, which are are too unwieldy for ordinary humans to work with). Here, commit * is the common starting point, so for Git to combine your changes on your branch, Git must compare commit C—your latest work—to commit *, to see what you changed:

git diff --find-renames <hash-of-*> <hash-of-C>   # what you changed

Likewise, Git must compare commit F—their latest work—to commit *, to see what they changed:

git diff --find-renames <hash-of-*> <hash-of-F>   # what they changed

Git can now combine the two sets of changes. If you modified line 12 of some file, but they did not, Git takes your change. If they modified line 20 of that same file, but you did not, Git takes their change. Both changes get applied to that one file as it appears in commit *, to make the merged version of that file.

(For a real merge, eventually, Git makes a merge commit, which remembers both branch tips, but for cherry-pick that does not happen.)

Cherry-pick uses this same merge machinery to accomplish a cherry-pick, but this time, the merge base is not some common starting commit. Instead, it's the parent of the commit whose name or hash ID you give to git cherry-pick:

...--o--o--o--o--A   <-- master (HEAD)
      \
       o--o--B--C   <-- test_imu

If you are in this situation, with commit A being your current commit because you are on master, and you issue the command:

git cherry-pick test_imu

Git makes a merge with the merge base being commit B—the parent of commit C, which is the commit you are picking—and commits C and A being the two commits that get compared:

git diff --find-renames <hash-of-B> <hash-of-A>   # what you did
git diff --find-renames <hash-of-B> <hash-of-C>   # what they did

Git now combines these changes. You get a merge conflict where you both made differing changes, but to the same line(s) of the same file.

If the if test is removed by going from commit B to commit A, but nothing in B-to-C touches the if test, Git assumes that the correct action is to keep the removal of the if test. The only way to know for sure why Git did what Git did, though, is to look at the three inputs, e.g., by running those two git diff commands.

I find it quite helpful to set merge.conflictStyle to diff3, so that when there is a conflict, Git includes the base-commit file section, as well as the two conflicting changes. This often makes it unnecessary to look at commit B directly. In particularly complex cases, though, you may want to look at all three inputs.