Cherry picking a commit from a branch rebased to a different commit pulls in more history than desired

Question

I have a branch structure like follows. 3 branches.

a - b - c - d  *main*
     \
      e - f    *feature1*
           \
            h  *feature2*

I was originally developing feature1 and then I started developing feature2. feature2 actually does not rely on code changes from feature1 but I wanted to be able to test them together. Figuring that feature1 would get on main before feature2.

Plans changed. Now feature2 is going to come in first. So what I want to do is essentially cherry-pick commit h into main.

When I look at the diff for h it is perfect. The changes on h are precisely what I want. Again feature1 and feature2 do not rely on each other from a code standpoint just testing/development standpoint.

The problem is when I am on main trying to cherry-pick in commit h it does not just bring in commit h. Commit e and f are in there too. I don't think they are like actually in there but since lines have merge conflicts when I am resolving those merge conflicts e and f are there.

Why is this happening? How can I get around this? Is there some requirement of the branches that you are cherry picking to/from.

Answer 1

You should be able to do either of the following:

• from main

git cherry-pick -x h

• from feature2

git rebase --onto main f feature2

The second would work if you had MORE than just h and didnt want to do multiple cherry picks. It will put h' and any other commits after h' on feature2 ontop of d on main.

The first command should cherry pick the commit h' based upon h onto main after d' and it should denote where it come from in the commit message which many people find handy.