tags:

views:

228

answers:

1

Documentation says: "Because git-cherry compares the changeset rather than the commit id (sha1), you can use git-cherry to find out if a commit you made locally has been applied under a different commit id."

Let's see:

$ git cherry master release-1.1.0 | head -1
- 533e2559342910fbffa2be5b38fdd7f2ddb2ed53
$ git show 533e2559342910fbffa2be5b38fdd7f2ddb2ed53
...
(cherry picked from commit 409c61b3304373a73c787fdf9c08cc338934b74d)
...

git show shows the same changeset for 409c.. and 533e

$ git br --contains 533e2559342910fbffa2be5b38fdd7f2ddb2ed53
release-1.1.0
$ git br --contains 409c61b3304373a73c787fdf9c08cc338934b74d
master
release-1.0.4

That means that the changeset is in both master and release-1.1.0. So how come git cherry shows 533e.. ?

+3  A: 

It also says "The commits are compared with their patch id, obtained from the git-patch-id program.". When applied your cherry-picked diff, did it perchance end up being a slightly different diff?

In that case not only will the the commit id differ, but also the patch id as git-patch-id will report different patch ids for the commits and thus they won't be considered to be in each others' branches.

It's easy to check for this:

git show 533e2559342910fbffa2be5b38fdd7f2ddb2ed53 | git-patch-id
git show 409c61b3304373a73c787fdf9c08cc338934b74d | git-patch-id

If the first sha1 returned by git-patch-id differs between the both runs, that is what has happened.

Caveat lector -- I haven't tried my theory, but that's how I interpret the man-pages.

Henrik Gustafsson
I don't have git-patch-id in my path, but 'git patch-id' does work.
Erik Hesselink