Re: Finding a commit

From: Soham Mehta <soham@box.net>
Date: Oct 22, 2009, 08:32 UTC
Message-ID: <4AE018B2.2010408@box.net>

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:

Show 36 quoted lines

> On Wed, Oct 21, 2009 at 2:37 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>   
>>> 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
>>
>>  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
>