{"thread":{"id":"34105","subject":"Exact format of tree objets","startedAt":"2013-06-11T16:25:14Z","lastAt":"2013-06-18T17:47:04Z","messageCount":7,"participants":["Chico Sokol","Ilari Liusvaara","Junio C Hamano","Jakub Narebski","Thomas Rast"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"220456","messageId":"CABx5MBRAYmO39BnMqnHZhUOwQf-7yeRuD=m7-P2xXdhkp6aWpA@mail.gmail.com","threadId":"34105","inReplyTo":null,"subject":"Exact format of tree objets","fromName":"Chico Sokol","fromEmail":"chico.sokol@gmail.com","sentAt":"2013-06-11T16:25:14Z","receivedAt":"2013-06-11T16:25:14Z","isPatch":false,"sender":{"key":"chico.sokol@gmail.com","avatar":"https://gravatar.com/avatar/d15de6acd103ae702fa27f716c4569db8e12d8b70f8d5910db7864235c687fc2?d=mp&s=160"},"body":"Is there any official documentation of tree objets format? Are tree\nobjects encoded specially in some way? How can I parse the inflated\ncontents of a tree object?\n\nWe're suspecting that there is some kind of special format or\nencoding, because the command \"git cat-file -p <sha>\" show me the\nexpected output, something like:\n\n100644 blob 2beae51a0e14b3167fd7e81119972caef95779f4    .gitignore\n100644 blob 7c817960e954f0278a6eee8d58611f61445167e8    LICENSE.txt\n100644 blob 30e849cba985d74bfd29696f6dee5a40abaacb03    README\n...\n\n\nWhile \"git cat-file tree <sha>\" generate an strange output, which\nindicate some kink of encoding problem. Something like:\n\n100644 .gitignore+��▒����,��Wy�100644\nLICENSE.txt|�y`�T�'�n��XaaDQg�100644 README0�I˩��K�)\n\n\nThanks,\n\n\n\n\n\n\n\n--\nChico Sokol\n"},{"id":"220485","messageId":"20130611182649.GA24704@LK-Perkele-VII","threadId":"34105","inReplyTo":"CABx5MBRAYmO39BnMqnHZhUOwQf-7yeRuD=m7-P2xXdhkp6aWpA@mail.gmail.com","subject":"Re: Exact format of tree objets","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2013-06-11T18:26:49Z","receivedAt":"2013-06-11T18:26:49Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Tue, Jun 11, 2013 at 01:25:14PM -0300, Chico Sokol wrote:\n> Is there any official documentation of tree objets format? Are tree\n> objects encoded specially in some way? How can I parse the inflated\n> contents of a tree object?\n\nTree object consists of entries, each concatenation of:\n- Octal mode (using ASCII digits 0-7).\n- Single SPACE (0x20)\n- Filename\n- Single NUL (0x00)\n- 20-byte binary SHA-1 of referenced object.\n\nAt least following octal modes are known:\n40000: Directory (tree).\n100644: Regular file (blob).\n100755: Executable file (blob).\n120000: Symbolic link (blob).\n160000: Submodule (commit).\n\nThe entries are always sorted in (bytewise) lexicographical order,\nexcept directories sort like there was impiled '/' at the end.\n\nSo e.g.:\n! < 0 < 9 < a < a- < a- (directory) < a (directory) < a0 < ab < b < z.\n\n\nThe idea of sorting directories specially is that if one recurses\nupon hitting a directory and uses '/' as path separator, then the\nfull filenames are in bytewise lexicographical order.\n\n-Ilari\n"},{"id":"220486","messageId":"7v4nd4bigv.fsf@alter.siamese.dyndns.org","threadId":"34105","inReplyTo":"CABx5MBRAYmO39BnMqnHZhUOwQf-7yeRuD=m7-P2xXdhkp6aWpA@mail.gmail.com","subject":"Re: Exact format of tree objets","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-11T18:38:56Z","receivedAt":"2013-06-11T18:38:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chico Sokol <chico.sokol@gmail.com> writes:\n\n> Is there any official documentation of tree objets format? Are tree\n> objects encoded specially in some way? How can I parse the inflated\n> contents of a tree object?\n>\n> We're suspecting that there is some kind of special format or\n> encoding, because the command \"git cat-file -p <sha>\" show me ...\n> While \"git cat-file tree <sha>\" generate ...\n\n\"cat-file -p\" is meant to be human-readable form.  The latter gives\nthe exact byte contents read_sha1_file() sees, which is a binary\nformat.  Essentially, it is a sequence of:\n\n - mode of the entry encoded in octal, without any leading '0' pad;\n - pathname component of the entry, terminated with NUL;\n - 20-byte SHA-1 object name.\n\nsorted in a particular order.\n"},{"id":"220614","messageId":"loom.20130612T160455-551@post.gmane.org","threadId":"34105","inReplyTo":"7v4nd4bigv.fsf@alter.siamese.dyndns.org","subject":"Re: Exact format of tree objets","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2013-06-12T14:06:24Z","receivedAt":"2013-06-12T14:06:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano <gitster <at> pobox.com> writes:\n> Chico Sokol <chico.sokol <at> gmail.com> writes:\n> \n> > Is there any official documentation of tree objets format? Are tree\n> > objects encoded specially in some way? How can I parse the inflated\n> > contents of a tree object?\n> >\n> > We're suspecting that there is some kind of special format or\n> > encoding, because the command \"git cat-file -p <sha>\" show me ...\n> > While \"git cat-file tree <sha>\" generate ...\n> \n> \"cat-file -p\" is meant to be human-readable form.  The latter gives\n> the exact byte contents read_sha1_file() sees, which is a binary\n> format.  Essentially, it is a sequence of:\n> \n>  - mode of the entry encoded in octal, without any leading '0' pad;\n>  - pathname component of the entry, terminated with NUL;\n>  - 20-byte SHA-1 object name.\n\nI always wondered why this is the sole object format where SHA-1 is in 20-\nbyte binary format and not 40-chars hexadecimal string format...\n\n-- \nJakub Narębski\n"},{"id":"221219","messageId":"CABx5MBSFxpp4S8utMu5F_-VE-g4n98h67Rf+NfB=7bSk5qrq5w@mail.gmail.com","threadId":"34105","inReplyTo":"loom.20130612T160455-551@post.gmane.org","subject":"Re: Exact format of tree objets","fromName":"Chico Sokol","fromEmail":"chico.sokol@gmail.com","sentAt":"2013-06-18T13:53:29Z","receivedAt":"2013-06-18T13:53:29Z","isPatch":false,"sender":{"key":"chico.sokol@gmail.com","avatar":"https://gravatar.com/avatar/d15de6acd103ae702fa27f716c4569db8e12d8b70f8d5910db7864235c687fc2?d=mp&s=160"},"body":"Thanks!\n\nBy the way, where can I find this kind of specification? I couldn't\nfind the spec of tree objects here:\nhttps://github.com/git/git/tree/master/Documentation\n\n\n--\nChico Sokol\n\n\nOn Wed, Jun 12, 2013 at 11:06 AM, Jakub Narebski <jnareb@gmail.com> wrote:\n> Junio C Hamano <gitster <at> pobox.com> writes:\n>> Chico Sokol <chico.sokol <at> gmail.com> writes:\n>>\n>> > Is there any official documentation of tree objets format? Are tree\n>> > objects encoded specially in some way? How can I parse the inflated\n>> > contents of a tree object?\n>> >\n>> > We're suspecting that there is some kind of special format or\n>> > encoding, because the command \"git cat-file -p <sha>\" show me ...\n>> > While \"git cat-file tree <sha>\" generate ...\n>>\n>> \"cat-file -p\" is meant to be human-readable form.  The latter gives\n>> the exact byte contents read_sha1_file() sees, which is a binary\n>> format.  Essentially, it is a sequence of:\n>>\n>>  - mode of the entry encoded in octal, without any leading '0' pad;\n>>  - pathname component of the entry, terminated with NUL;\n>>  - 20-byte SHA-1 object name.\n>\n> I always wondered why this is the sole object format where SHA-1 is in 20-\n> byte binary format and not 40-chars hexadecimal string format...\n>\n> --\n> Jakub Narębski\n>\n>\n>\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"221238","messageId":"CABx5MBTtvyZT+TUj6iibFngbMnGoDvFT2wXM6oDACtuJ46kR7Q@mail.gmail.com","threadId":"34105","inReplyTo":"20130611182649.GA24704@LK-Perkele-VII","subject":"Re: Exact format of tree objets","fromName":"Chico Sokol","fromEmail":"chico.sokol@gmail.com","sentAt":"2013-06-18T15:15:52Z","receivedAt":"2013-06-18T15:15:52Z","isPatch":false,"sender":{"key":"chico.sokol@gmail.com","avatar":"https://gravatar.com/avatar/d15de6acd103ae702fa27f716c4569db8e12d8b70f8d5910db7864235c687fc2?d=mp&s=160"},"body":"What is the encoding of the filename?\n\n\n--\nChico Sokol\n\n\nOn Tue, Jun 11, 2013 at 3:26 PM, Ilari Liusvaara\n<ilari.liusvaara@elisanet.fi> wrote:\n> On Tue, Jun 11, 2013 at 01:25:14PM -0300, Chico Sokol wrote:\n>> Is there any official documentation of tree objets format? Are tree\n>> objects encoded specially in some way? How can I parse the inflated\n>> contents of a tree object?\n>\n> Tree object consists of entries, each concatenation of:\n> - Octal mode (using ASCII digits 0-7).\n> - Single SPACE (0x20)\n> - Filename\n> - Single NUL (0x00)\n> - 20-byte binary SHA-1 of referenced object.\n>\n> At least following octal modes are known:\n> 40000: Directory (tree).\n> 100644: Regular file (blob).\n> 100755: Executable file (blob).\n> 120000: Symbolic link (blob).\n> 160000: Submodule (commit).\n>\n> The entries are always sorted in (bytewise) lexicographical order,\n> except directories sort like there was impiled '/' at the end.\n>\n> So e.g.:\n> ! < 0 < 9 < a < a- < a- (directory) < a (directory) < a0 < ab < b < z.\n>\n>\n> The idea of sorting directories specially is that if one recurses\n> upon hitting a directory and uses '/' as path separator, then the\n> full filenames are in bytewise lexicographical order.\n>\n> -Ilari\n"},{"id":"221276","messageId":"87bo73b9bb.fsf@linux-k42r.v.cablecom.net","threadId":"34105","inReplyTo":"CABx5MBTtvyZT+TUj6iibFngbMnGoDvFT2wXM6oDACtuJ46kR7Q@mail.gmail.com","subject":"Re: Exact format of tree objets","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-06-18T17:47:04Z","receivedAt":"2013-06-18T17:47:04Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Chico Sokol <chico.sokol@gmail.com> writes:\n\n> What is the encoding of the filename?\n\nGit just considers filename a bunch of bytes that form a posix filename\n(i.e., may not contain '/' and '\\0').  So depending on your point of\nview, it's either \"no encoding\" or \"whatever you put into it\".\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"}]}