{"id":146,"date":"2007-07-07T15:32:07","date_gmt":"2007-07-07T13:32:07","guid":{"rendered":"http:\/\/web.glandium.org\/blog\/?p=146"},"modified":"2010-01-27T08:52:31","modified_gmt":"2010-01-27T07:52:31","slug":"finding-where-a-tarball-came-from-with-git","status":"publish","type":"post","link":"https:\/\/glandium.org\/blog\/?p=146","title":{"rendered":"Finding where a tarball came from with git"},"content":{"rendered":"

I got the idea reading this question on the webkit-dev list<\/a>, and from my recollection of the git documentation<\/a>. Well, for the webkit case, the basic script I put up would be of no help because the tarballs don't contain all the files (plus, they use subversion, not git, so it would also require a long importing process). Anyways...<\/p>\n

Considering how SHA-1 hashes of objects are created with git, it is actually pretty easy to generate a SHA-1 hash from a random (non-git) tree, and then, the corresponding commit. First, you have git-hash-object<\/code> that helps you creating a hash for a particular object (though it's also trivial to do with sha1sum<\/code>). For regular files, git-hash-object -t blob $filename<\/code> is enough. For symbolic links, you have to read the link destination, and give it without<\/b> a trailing character (be it the NULL character or a carriage return) to git-hash-object -t blob --stdin<\/code>. For directories, you have to generate a tree \"structure\" by yourself and pass it to git-hash-object -t tree --stdin<\/code>. I haven't bothered looking at other file types.<\/p>\n

The tree structure can be guessed by either looking at mktree.c<\/code> or at the output of git-cat-file tree $sha1<\/code> where $sha1<\/code> is the SHA-1 hash for a tree object. It contains 3 informations for each node in the tree : the file mode, with the same format as what stat()<\/code> returns, except for some reason, permissions are 000 for directories and symbolic links ; the file name ; and the SHA-1 hash. These informations are written with the following format : file mode in octal ascii and no padding zero (\"%o\") followed by a space character, then the filename followed by a NULL character, and the binary form of the SHA-1 hash.<\/p>\n

Nodes are sorted in a not-so-quite lexical order (take a look at base_name_compare<\/code> in read-cache.c<\/code>) and are not separated by any special character: the mode of a file just follows the SHA-1 hash of its predecessor.<\/p>\n

With all this new knowledge, you should be able to write some code that would return the SHA-1 from an arbitrary directory. Okay, since you must be at least as lazy as I am, you can take the script I wrote<\/a>.<\/p>\n

Now, let's take a look at a real life case : what commit is the latest nightly snapshot for the linux kernel from ? First, download the latest snapshot patch and its baseline, and extract the whole. Then, run my git-hash-tree.pl<\/a><\/code> script with the directory containing the extracted kernel as an argument. It will return, after a while, the SHA-1 hash for the whole tree. During this long process, you also have plenty of time to git clone<\/code> linus's tree.<\/p>\n

Once you're all done, you can search for the commit corresponding to the tree hash (let's call it $hash<\/code>) with the following command :<\/p>\n

git-rev-list --all | while read h; do git-cat-file commit $h | grep -q \"^tree $hash\" && echo $h && break; done
\n<\/code><\/p><\/blockquote>\n

If you just followed these steps, you should just have spent a great moment having no result at all. There are actually 2 things that prevent this method to properly work with the linux kernel nightlies :<\/p>\n