# Finding a commit

5 messages from 2009-10-21 to 2009-10-21. Participants: Soham Mehta, Daniele Segato, Thomas Rast, Douglas Campos.
Thread: https://gitlist.dev/t/21302

## Soham Mehta, 2009-10-21 11:29

Subject: Finding a commit
Message-ID: <4ADEF095.3020406@box.net>
URL: https://gitlist.dev/e/4ADEF095.3020406%40box.net

```
Given a SHA1 of a commit from one repository (say x), wondering what is 
a proper way to find out if that commit (change) also exists in a 
different repository (say y).

Because SHA1 can change if a commit is cherry-picked around, I cannot 
just grep for that SHA1 from git-rev-list or git-log on 'y'. I need a 
way to know if a commit with identical changes (as in 'x') is also 
present in 'y'.

I realize that Author and Timestamp do not change when the commit is 
moved (fetched, pushed, pulled, rebased, cherry-picked etc). So my 
current solution relies on grepping for the pair of Author-Timestamp 
from git-log on 'y'.

Wondering if there is more appropriate way of doing this?

Thanks.
-Soham

```

## Daniele Segato, 2009-10-21 12:30

Subject: Re: Finding a commit
Message-ID: <9accb4400910210530k75a763cbtbc9294d937de9242@mail.gmail.com>
URL: https://gitlist.dev/e/9accb4400910210530k75a763cbtbc9294d937de9242%40mail.gmail.com
In-Reply-To: <4ADEF095.3020406@box.net>

```
On Wed, Oct 21, 2009 at 1:29 PM, Soham Mehta <soham@box.net> wrote:
> Because SHA1 can change if a commit is cherry-picked around, I cannot just
> grep for that SHA1 from git-rev-list or git-log on 'y'. I need a way to know
> if a commit with identical changes (as in 'x') is also present in 'y'.

I'm really not an expert of git..

but A commit is something like:

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..

But I don't know how you can get the SHA-1 of the tree from a commit
(may be git cat-file <commit-sha> could help you)
and I don't know how to search for that tree around your index...

But I'm sure google (or whatever) has the answer to those questions,

regards,
Daniele

```

## Thomas Rast, 2009-10-21 12:37

Subject: Re: Finding a commit
Message-ID: <200910211437.39166.trast@student.ethz.ch>
URL: https://gitlist.dev/e/200910211437.39166.trast%40student.ethz.ch
In-Reply-To: <9accb4400910210530k75a763cbtbc9294d937de9242@mail.gmail.com>

```
Daniele Segato wrote:
> On Wed, Oct 21, 2009 at 1:29 PM, Soham Mehta <soham@box.net> wrote:
> > Because SHA1 can change if a commit is cherry-picked around, I cannot just
> > grep for that SHA1 from git-rev-list or git-log on 'y'. I need a way to know
> > if a commit with identical changes (as in 'x') is also present in 'y'.

man git-patch-id (online at http://git.or.cz/man/git-patch-id).

Note that if the cherry-pick conflicted, you'll get a different
patch-id.

> I'm really not an expert of git..
> 
> but A commit is something like:
> 
> 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.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

```

## Douglas Campos, 2009-10-21 13:26

Subject: Re: Finding a commit
Message-ID: <ed88cb980910210626t750b4cc2r91d1dc22df14eb8b@mail.gmail.com>
URL: https://gitlist.dev/e/ed88cb980910210626t750b4cc2r91d1dc22df14eb8b%40mail.gmail.com
In-Reply-To: <4ADEF095.3020406@box.net>

```
On Wed, Oct 21, 2009 at 9:29 AM, Soham Mehta <soham@box.net> wrote:
> Given a SHA1 of a commit from one repository (say x), wondering what is a
> proper way to find out if that commit (change) also exists in a different
> repository (say y).
>
> Because SHA1 can change if a commit is cherry-picked around, I cannot just
> grep for that SHA1 from git-rev-list or git-log on 'y'. I need a way to know
> if a commit with identical changes (as in 'x') is also present in 'y'.
>
> I realize that Author and Timestamp do not change when the commit is moved
> (fetched, pushed, pulled, rebased, cherry-picked etc). So my current
> solution relies on grepping for the pair of Author-Timestamp from git-log on
> 'y'.
>

Have you tried git cherry?


-- 
Douglas Campos (qmx)
+55 11 7626 5959

```

## Daniele Segato, 2009-10-21 13:55

Subject: Re: Finding a commit
Message-ID: <9accb4400910210655i115686c5h2d38a885c1d56d2e@mail.gmail.com>
URL: https://gitlist.dev/e/9accb4400910210655i115686c5h2d38a885c1d56d2e%40mail.gmail.com
In-Reply-To: <200910211437.39166.trast@student.ethz.ch>

```
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

```
