threads / discuss / 14924

Git tree/blob and corresponding commit

Subject: Git tree/blob and corresponding commit

## tl;dr

5 messages between Aug 10, 2008 and Aug 15, 2008.

replies: 4people: 3as markdown or json

Pascal Obry· Aug 10, 2008, 17:08 UTC · lore

Something I'm trying to figure out and can't find the answer myself. I'm browsing a tree, for example:

    $ git ls-tree HEAD~100

This list a set of files with the corresponding blob. Each blob has it's own SHA1. Fine.

Now given a SHA1 I'd like to know which commit has created (was containing) this specific blob?

What is the best way to achieve that?

Thanks.

-- 
--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Jonathan Nieder· Aug 10, 2008, 20:38 UTC · re: Pascal Obry · lore

Re: Git tree/blob and corresponding commit

Pascal Obry wrote:

> Now given a SHA1 I'd like to know which commit has created (was containing)
> this specific blob?

Why do you want to know? The right method depends on your reason. You probably know more than I do about this, but here are my thoughts.

If some loose object of yours got corrupted and you are trying to see what exactly is missing, then (for this task) you are in luck. See <http://www.kernel.org/pub/software/scm/git/docs/howto/recover-corrupted-blob-object.txt>.

If some packed object got corrupted, I'd be interested to hear how this is handled. I think there was discussion recently of how to recover from that situation. If you have the luxury, it might be good to use unpack-objects to get to the first situation.

But I think that is not your situation. I'll assume for definiteness that some source file appeared out of thin air in your /lost+found and you are trying to figure out what it is. Then see <http://thread.gmane.org/gmane.comp.version-control.git/44750/focus=44754> and surrounding discussion. You could use "git ls-tree -r" if you do not have the filename.

Hope that helps, Jonathan

Jonathan Nieder· Aug 10, 2008, 20:44 UTC · re: Jonathan Nieder · lore

Re: Git tree/blob and corresponding commit

I wrote:

> see
> <http://thread.gmane.org/gmane.comp.version-control.git/44750/focus=44754>

but I actually meant <http://thread.gmane.org/gmane.comp.version-control.git/44750/focus=44849>. Anyway, the whole thread is interesting. Sorry for the noise.

Sincerely, Jonathan

Pascal Obry· Aug 14, 2008, 14:02 UTC · re: Jonathan Nieder · lore

Re: Git tree/blob and corresponding commit

Jonathan,

> but I actually meant
> <http://thread.gmane.org/gmane.comp.version-control.git/44750/focus=44849>.
> Anyway, the whole thread is interesting.  Sorry for the noise.

Thanks, I had a look. This is indeed giving some procedure... I was hopping for something faster (git rev-list takes some time!).

-- 
--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Bryan Donlan· Aug 15, 2008, 19:39 UTC · re: Pascal Obry · lore

Re: Git tree/blob and corresponding commit

On Thu, Aug 14, 2008 at 10:02 AM, Pascal Obry <pascal@obry.net> wrote:

Show 9 quoted lines

> Jonathan,
>
>> but I actually meant
>>
>> <http://thread.gmane.org/gmane.comp.version-control.git/44750/focus=44849>.
>> Anyway, the whole thread is interesting.  Sorry for the noise.
>
> Thanks, I had a look. This is indeed giving some procedure... I was hopping
> for something faster (git rev-list takes some time!).

It's not really meant to be a common case; if the same file is created under different names by different commits that aren't ancestors of each other, then it's unclear which should be reported. As such, there's no index or other such thing to quickly find the commits corresponding to a blob, so you just have to walk the entire history.