CODEWITHSUNDEEP
gitdvcsgit-cherry
Maciej Lotkowski
Maciej Lotkowski

Reputation: 662

git cherry confusion - doesn't work as described in doc

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 branch --contains 533e2559342910fbffa2be5b38fdd7f2ddb2ed53
release-1.1.0
$ git branch --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.. ?

Upvotes: 6

Views: 594

Answers (2)

Guildenstern
Guildenstern

Reputation: 3754

git cherry master release-1.1.0 is saying that:

  1. 533e25593 is on release-1.1.0; and
  2. there is some commit on master which is patch-id equivalent to 533e25593 but not the same commit.

Note that git-cherry(1) reports the hash on release-1.1.0. So we still don’t know what that patch-id equivalent is on master. (git cherry -v can help.)

Interestingly we see that 533e25593 is a cherry-pick from some other commit.

Then your git branch --contains... calls say that:

  1. 533e25593 is on release-1.1.0 and only that branch
    • Confirming git-cherry(1)
  2. 409c61b3 (what the cherry-pick in (1) is from) is both on master and release-1.0.4

What seems to have happened:

  1. 409c61b3 was committed on release-1.0.4
  2. That commit was cherry-picked to release-1.0.4, becoming the commit 533e25593
  3. release-1.0.4 was eventually merged into master
    • Since 409c61b3 is reachable from master
  4. release-1.1.0 was not merged into master

Are 409c61b3 and 533e25593 patch-id equivalent?

Unsure. You would have to run git cherry release-1.1.0 release-1.0.4 to find out.

More stable patch-id output

Note that you can use git cherry --stable to get a more stable/reliable patch-id.

Upvotes: 0

Henrik Gustafsson
Henrik Gustafsson

Reputation: 54108

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.

Upvotes: 4

Related Questions