Skip to contentSkip to conversation

Finding a commit

DISCUSSION Soham Mehta 1 participant 1 message Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

Thanks for all the answers! Sorry for the delayed reply.

Like Douglas Campos suggested, git-cherry (which uses git-patch-id like Thomas Rast suggests) works for me. Here is what I tried:

from first repo$: git fetch second-repo
from first repo$: git cherry -v second-repo/branch-in-question sha1 sha1^
- sha1 <commit message>

Outputs the sha1 with a minus sign in front, which means the change is already present in second-repo/branch-in-question, and is what I expect.

-Soham

thus spake Daniele Segato , On 10/21/2009 6:55 AM:

Quoted 36 lines · Thomas Rast
Quoted 17 lines
Quoted 10 lines

Commit -> Tree ---> Blob1, Blob2, Blob3

Commit, Trees and Blobs are all identified by sha1 the commit should keep information on the author, the "parent" commit(s) and so on..
the tree should just keep the "snapshot" of the data..

so I think that if you search for the SHA-1 of the tree you should be fine..

Not if you really want to find out if X was cherry-picked into this repository, because the tree is the *final state* at that commit, which of course includes all preceding changes.

So suppose you have two patches A.diff and B.diff introducing files of the same name; then if you combine them into history as

Quoted 9 lines

A -- B

the tree state at B has both files, and hence is different from the tree state of B' in

B' -- A'

because there it only has the file B.

Yes... obviously...
the tree is the snapshot of a complete data set: so if you apply the same patch to different data set you get different trees... thanks for pointing it out.. :)

Regards,
Daniele