Re: identifying blobs (was Re: Memory overrun in http-push.c)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Fri, 2 Mar 2007, Junio C Hamano wrote:
> 
> It wasn't that identifying the commit that contained the version
> of the file was not needed.  It is just there already is a way
> to do so, and "to create git command" turns out to be
> unnecessary.  Something like:
> 
> 	$ hash=`git hash-object --stdin <$file_in_question`
> 	$ git log -z --raw -r --abbrev=40 |
>           grep -z '^:[0-7][0-7]* [0-7][0-7]* [0-9a-f][0-9a-f]* '"$hash"'

That's not very nice, because if the blob is already in the *top* commit, 
and isn't changed in a long long time, you'll not see it until it changes 
(which is potentially at the root commit when it was introduced).

So it's better to do something like

 - get the hash

	hash=`git hash-object --stdin <$file_in_question`

 - see if it is in the current top of the tree

	git ls-tree -r HEAD | cut -d3- | grep ^$hash

 - after that, start doing the backwards searching for things where it 
   went away if it was there before (roughly your "git log -z ...")

which should be fairly simple and straightforward.

For extra bonus points, the script could be trivially written so that it 
allows the user to specify a path limiter, so that you say "can you tell 
me which version this blob existed in, but I only want to know about 
drivers/scsi/ and include/scsi/"

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]