"git log -- SHA-1" - how to get/simulate this functionality?

"git log -- SHA-1" - how to get/simulate this functionality?

[Eugene Sajine]

Hi,

I'm wondering if there is a way to get some repo information if the
only thing i know is SHA-1 (no full path to the file)
The current way seems to be a bit cumbersome

git log --no-abbrev --raw --all | grep SHA-1

parse for path(s) and then git log -- path...

I would want something like git log -- SHA-1

Any ideas?

Thanks,
Eugene

Re: "git log -- SHA-1" - how to get/simulate this functionality?

[Eugene Sajine]

On Mon, Apr 26, 2010 at 1:54 PM, Eugene Sajine <euguess@gmail.com> wrote:
> Hi,
>
> I'm wondering if there is a way to get some repo information if the
> only thing i know is SHA-1 (no full path to the file)

I mean of course the SHA-1 of the blob, i.e. the result of git
hash-object some_file


Thanks,
Eugene

Re: "git log -- SHA-1" - how to get/simulate this functionality?

[Alex Riesen]

On Mon, Apr 26, 2010 at 19:56, Eugene Sajine <euguess@gmail.com> wrote:
> On Mon, Apr 26, 2010 at 1:54 PM, Eugene Sajine <euguess@gmail.com> wrote:
>> Hi,
>>
>> I'm wondering if there is a way to get some repo information if the
>> only thing i know is SHA-1 (no full path to the file)
>
> I mean of course the SHA-1 of the blob, i.e. the result of git
> hash-object some_file

Try 'git cat-file -t <sha>'. It prints what object type is under the hash.
Than you can use either 'git cat-file <type> <sha>' (the most precise version,
which shall fail if anything is wrong), 'git cat-file -p <sha>' or plain
'git show <sha>' (which always works, unless repo's broken).

Re: "git log -- SHA-1" - how to get/simulate this functionality?

[Eugene Sajine]

On Mon, Apr 26, 2010 at 2:08 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Mon, Apr 26, 2010 at 19:56, Eugene Sajine <euguess@gmail.com> wrote:
>> On Mon, Apr 26, 2010 at 1:54 PM, Eugene Sajine <euguess@gmail.com> wrote:
>>> Hi,
>>>
>>> I'm wondering if there is a way to get some repo information if the
>>> only thing i know is SHA-1 (no full path to the file)
>>
>> I mean of course the SHA-1 of the blob, i.e. the result of git
>> hash-object some_file
>
> Try 'git cat-file -t <sha>'. It prints what object type is under the hash.
> Than you can use either 'git cat-file <type> <sha>' (the most precise version,
> which shall fail if anything is wrong), 'git cat-file -p <sha>' or plain
> 'git show <sha>' (which always works, unless repo's broken).
>

Well thank you for that, but that gives me what i already know - the content.
I need to "reverse engineer" the history by having only the content
and its SHA-1 in order to indentify the last commitID and get all
relevant info (author, date etc. )

This is all about avoiding using keyword expansion (thanks CVS for bad habbits)

Thanks,
Eugene

Re: "git log -- SHA-1" - how to get/simulate this functionality?

[Alex Riesen]

On Mon, Apr 26, 2010 at 20:22, Eugene Sajine <euguess@gmail.com> wrote:
> On Mon, Apr 26, 2010 at 2:08 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
>> On Mon, Apr 26, 2010 at 19:56, Eugene Sajine <euguess@gmail.com> wrote:
>>> On Mon, Apr 26, 2010 at 1:54 PM, Eugene Sajine <euguess@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I'm wondering if there is a way to get some repo information if the
>>>> only thing i know is SHA-1 (no full path to the file)
>>>
>>> I mean of course the SHA-1 of the blob, i.e. the result of git
>>> hash-object some_file
>>
>> Try 'git cat-file -t <sha>'. It prints what object type is under the hash.
>> Than you can use either 'git cat-file <type> <sha>' (the most precise version,
>> which shall fail if anything is wrong), 'git cat-file -p <sha>' or plain
>> 'git show <sha>' (which always works, unless repo's broken).
>>
>
> Well thank you for that, but that gives me what i already know - the content.
> I need to "reverse engineer" the history by having only the content
> and its SHA-1 in order to indentify the last commitID and get all
> relevant info (author, date etc. )

Hmm. In that case, your using of git log look like a good way to get the
information. If you wanted an output format which is better suited for
automated parsing, you can look at "git rev-list --pretty=format:...",
let it output only commit and tree hashes, and grep the output of
"git ls-tree" for your hash...

> This is all about avoiding using keyword expansion (thanks CVS for bad habbits)
>
> Thanks,
> Eugene
>

Re: "git log -- SHA-1" - how to get/simulate this functionality?

[Alex Riesen]

On Mon, Apr 26, 2010 at 20:57, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Mon, Apr 26, 2010 at 20:22, Eugene Sajine <euguess@gmail.com> wrote:
>> Well thank you for that, but that gives me what i already know - the content.
>> I need to "reverse engineer" the history by having only the content
>> and its SHA-1 in order to indentify the last commitID and get all
>> relevant info (author, date etc. )
>
> Hmm. In that case, your using of git log look like a good way to get the
> information. If you wanted an output format which is better suited for
> automated parsing, you can look at "git rev-list --pretty=format:...",
> let it output only commit and tree hashes, and grep the output of
> "git ls-tree" for your hash...

Actually, "git log --no-abbrev --raw --oneline" looks very simple to parse.
By the way, you may get ambiguous results: any file any time could have
had the given hash. IOW, by looking at the whole history you may see different
files having the same hash. It does mean the same content, so maybe its
OK for your purposes.

Re: "git log -- SHA-1" - how to get/simulate this functionality?

[Eugene Sajine]

On Mon, Apr 26, 2010 at 3:37 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Mon, Apr 26, 2010 at 20:57, Alex Riesen <raa.lkml@gmail.com> wrote:
>> On Mon, Apr 26, 2010 at 20:22, Eugene Sajine <euguess@gmail.com> wrote:
>>> Well thank you for that, but that gives me what i already know - the content.
>>> I need to "reverse engineer" the history by having only the content
>>> and its SHA-1 in order to indentify the last commitID and get all
>>> relevant info (author, date etc. )
>>
>> Hmm. In that case, your using of git log look like a good way to get the
>> information. If you wanted an output format which is better suited for
>> automated parsing, you can look at "git rev-list --pretty=format:...",
>> let it output only commit and tree hashes, and grep the output of
>> "git ls-tree" for your hash...
>
> Actually, "git log --no-abbrev --raw --oneline" looks very simple to parse.
> By the way, you may get ambiguous results: any file any time could have
> had the given hash. IOW, by looking at the whole history you may see different
> files having the same hash. It does mean the same content, so maybe its
> OK for your purposes.
>

Yes this looks a bit better, but still not "grep"-able easily as grep
SHA-1 cuts off the commit ID.
I'm wondering why this "simple"  feature which actually solves
(almost) the problem of "keyword expansion" substitution for git once
and for all is not yet there...:(

While i do realize that i might have ambiguous results and first of
all because the same blob can exist in creation commits, modification
and move, but mostly people are interested in the last commit of this
particular file/blob. So, i would say, it is very rare that at any
given point of time there will be two objects with the same hash in
repo.

It is a feature request than:)

Please, somebody take a look at the possibility to develop a variant
of "git log" or rev-list which would show the commits in which the
given blob SHA-1 has participated.

Thanks,
Eugene