Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git cherry pick creates duplicate commits

After cherry-picking some commits from one branch to another branch, i still see commits when a pull request is created later.

Say for example, There is a git project which has two branches : Dev , Release.

And commit history is in following order.

DEV : a1, a2, a3, a4, a5, a6

RELEASE : a1, a2

Now if i cherry-picked commits a3 and a5 alone from Dev to Release. Now the commit history will be as shown below. cherry-picked commits will have new SHA (b1 & b2).

RELEASE : a1, a2, b1, b2.

Later if i try to create a pull request from Dev to Release branch, i stil see the commits a3 and a5.

But in this case how can i find difference in commits between these two branches?

I saw some articles stating 'rebase' but not able to understand the logic behind it.

like image 303
Sri Avatar asked Mar 29 '17 04:03

Sri


People also ask

Does cherry pick duplicate commits?

The reason why you should use cherry-pick rarely is that it easily creates "duplicate" commits: when you integrate a commit into your HEAD branch using cherry-pick, Git has to create a new commit with the exact same contents. It is, however, a completely new commit object with its own, new SHA identifier.

How does cherry pick work?

Cherry-picking works by figuring out the patch—that is, the changes—introduced by a given commit and then applying that patch to the current branch. That might result in conflicts if the commit you decided to cherry-pick builds on changes introduced by an earlier commit you didn't cherry-pick.

How do you fix cherry pick conflict?

One possible way to avoid these cherry-pick conflicts is by doing the cherry-picking in the order of oldest commit to latest commit, i.e. based on commit date.


1 Answers

Ideally, you rebase dev on top on the updated release first.

git checkout dev
git rebase release

The logic behind that is that Git should detect that a3 and a5 are the same as b1 and b2: meaning a3 and a5 won't be replayed at all.
The new dev branch (from which you will create a PR) won't have a3 and a5 anymore.

See also:

  • "git merge after git cherry-pick: avoiding duplicate commits"
  • "using git rebase to remove duplicate cherry-picked commits"
like image 174
VonC Avatar answered Sep 23 '22 20:09

VonC