{"thread":{"id":"28621","subject":"How pretty is pretty? git cat-file -p inconsistency","startedAt":"2011-10-07T08:44:48Z","lastAt":"2011-10-08T16:36:32Z","messageCount":6,"participants":["Michael J Gruber","Junio C Hamano","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"177142","messageId":"4E8EBC00.90909@drmicha.warpmail.net","threadId":"28621","inReplyTo":null,"subject":"How pretty is pretty? git cat-file -p inconsistency","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-10-07T08:44:48Z","receivedAt":"2011-10-07T08:44:48Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"diff <(git cat-file -p tags/v1.7.7) <(git cat-file tag tags/v1.7.7)\n4c4\n< tagger Junio C Hamano Fri Sep 30 14:21:06 2011 -0700\n---\n> tagger Junio C Hamano 1317417666 -0700\n\nvs.\n\ndiff <(git cat-file -p tags/v1.7.7^{}) <(git cat-file commit tags/v1.7.7^{})\n\n(no diff)\n\nThat is, \"cat file -p\" pretty prints dates for tag objects but not for\ncommit objects. In fact, \"-p\" on commit objects does not prettify at all\ncompared to the raw content. Is that intentional? I'd suggest\nprettifying dates with \"-p\" for commit objects also. But just how\nplumbing is the \"-p\" mode of \"cat-file\"?\n\nMichael\n"},{"id":"177170","messageId":"7v62k0wudg.fsf@alter.siamese.dyndns.org","threadId":"28621","inReplyTo":"4E8EBC00.90909@drmicha.warpmail.net","subject":"Re: How pretty is pretty? git cat-file -p inconsistency","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-07T18:04:43Z","receivedAt":"2011-10-07T18:04:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> That is, \"cat file -p\" pretty prints dates for tag objects but not for\n> commit objects. In fact, \"-p\" on commit objects does not prettify at all\n> compared to the raw content. Is that intentional?\n\n\"cat-file -p\" is an ill-conceived half-ass afterthought, and I do not\nthink anybody sane considers it as part of the \"plumbing\" ultra stable\ninterface for machine consumption. See a0f15fa (Pretty-print tagger\ndates., 2006-03-01).\n\n> I'd suggest\n> prettifying dates with \"-p\" for commit objects also.\n\nPlease make it so. It is your choice to do a patch to update this single\nthing first, or to discuss the output with \"-p\" for all the other object\ntypes at the same time to get the list concensus before proceeding.\n\nThanks.\n"},{"id":"177182","messageId":"4E8F6088.8060300@drmicha.warpmail.net","threadId":"28621","inReplyTo":"7v62k0wudg.fsf@alter.siamese.dyndns.org","subject":"Re: How pretty is pretty? git cat-file -p inconsistency","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-10-07T20:26:48Z","receivedAt":"2011-10-07T20:26:48Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 07.10.2011 20:04:\n> Michael J Gruber writes:\n> \n>> That is, \"cat file -p\" pretty prints dates for tag objects but not for\n>> commit objects. In fact, \"-p\" on commit objects does not prettify at all\n>> compared to the raw content. Is that intentional?\n> \n> \"cat-file -p\" is an ill-conceived half-ass afterthought, and I do not\n> think anybody sane considers it as part of the \"plumbing\" ultra stable\n> interface for machine consumption. See a0f15fa (Pretty-print tagger\n> dates., 2006-03-01).\n\nUh, I see. \"git cat-file -p tagname\" is a bit like the the missing \"git\ntag show tagname\" or \"git show tagname\" without the commit.\n\n> \n>> I'd suggest\n>> prettifying dates with \"-p\" for commit objects also.\n> \n> Please make it so. It is your choice to do a patch to update this single\n> thing first, or to discuss the output with \"-p\" for all the other object\n> types at the same time to get the list concensus before proceeding.\n\nI never knew how ugly the output of \"git tag-file tree sha1\" is. I guess\nit's the type of object whose format I don't know... We don't have an\nobject format description in Doc/technical, do we? tree.c doesn't tell\nme much.\n\nLooking at how \"cat-file -p\" for tags is done makes me not want to do it\nfor commits ;) We do have pretty \"git show\" for all types of objects,\nthough \"git cat-file -p treeobject\" is more informative than \"git show\ntreeobject\". I guess I have to make up my mind about what direction to go.\n\nMichael\n"},{"id":"177204","messageId":"m3r52o1hxr.fsf@localhost.localdomain","threadId":"28621","inReplyTo":"4E8F6088.8060300@drmicha.warpmail.net","subject":"Re: How pretty is pretty? git cat-file -p inconsistency","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-10-07T23:50:00Z","receivedAt":"2011-10-07T23:50:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael J Gruber writes:\n\n[cut]\n> I never knew how ugly the output of \"git tag-file tree sha1\" is. I guess\n> it's the type of object whose format I don't know... We don't have an\n> object format description in Doc/technical, do we? tree.c doesn't tell\n> me much.\n\nI had to handle this in my attempt to write \"git blame \" in Perl,\nwhich was using `git cat-file --batch`, and that gives raw data and not\npretty-printed.\n\nTree object consist of zero or more entries. Each item consist of mode,\nfilename, and sha1:\n\n SPC NUL \n\nwhere\n\n1. is variable-length (!) text (!) containing mode of an\n entry. It encodes type of entry: if it is blob (including special\n case: symbolic link), tree i.e. directory, or a commit\n i.e. submodule. Does not include leading zeros.\n\n2. is variable-length null-terminated (\"\\0\") name of a file\n or directory, or name of directory where submodule is attached\n\n3. is 40-bytes _binary_ identifier.\n\nHTH\n-- \nJakub Narębski\n"},{"id":"177218","messageId":"4E906292.1020909@drmicha.warpmail.net","threadId":"28621","inReplyTo":"m3r52o1hxr.fsf@localhost.localdomain","subject":"Re: How pretty is pretty? git cat-file -p inconsistency","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-10-08T14:47:46Z","receivedAt":"2011-10-08T14:47:46Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jakub Narebski venit, vidit, dixit 08.10.2011 01:50:\n> Michael J Gruber writes:\n> \n> [cut]\n>> I never knew how ugly the output of \"git tag-file tree sha1\" is. I guess\n>> it's the type of object whose format I don't know... We don't have an\n>> object format description in Doc/technical, do we? tree.c doesn't tell\n>> me much.\n> \n> I had to handle this in my attempt to write \"git blame \" in Perl,\n> which was using `git cat-file --batch`, and that gives raw data and not\n> pretty-printed.\n> \n> Tree object consist of zero or more entries. Each item consist of mode,\n> filename, and sha1:\n> \n> SPC NUL \n> \n> where\n> \n> 1. is variable-length (!) text (!) containing mode of an\n> entry. It encodes type of entry: if it is blob (including special\n> case: symbolic link), tree i.e. directory, or a commit\n> i.e. submodule. Does not include leading zeros.\n> \n> 2. is variable-length null-terminated (\"\\0\") name of a file\n> or directory, or name of directory where submodule is attached\n> \n> 3. is 40-bytes _binary_ identifier.\n> \n> HTH\n\nIt does help, thanks.\n\nThough I'm beginning to think we have a crazy object format. Not only do\nwe have a lot of indirections (like ascii representation of decimal\nrepresentation of length), but we store sha1 as ascii in commit and tag\nobjects and as binary in tree objects. Which makes tree objects the only\nunpleasant ones to look at (and parse) in raw form. (I was hoping we can\ndispose of/deprecate cat-file -p in favor of show). Oh well.\n\nMichael\n"},{"id":"177229","messageId":"201110081836.33941.jnareb@gmail.com","threadId":"28621","inReplyTo":"4E906292.1020909@drmicha.warpmail.net","subject":"Re: How pretty is pretty? git cat-file -p inconsistency","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-10-08T16:36:32Z","receivedAt":"2011-10-08T16:36:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 8 Oct 2011, Michael J Gruber wrote:\n> Jakub Narebski venit, vidit, dixit 08.10.2011 01:50:\n\n> > Tree object consist of zero or more entries. Each item consist of mode,\n> > filename, and sha1:\n> > \n> > SPC NUL \n> > \n> > where\n> > \n> > 1. is variable-length (!) text (!) containing mode of an\n> > entry. It encodes type of entry: if it is blob (including special\n> > case: symbolic link), tree i.e. directory, or a commit\n> > i.e. submodule. Does not include leading zeros.\n> > \n> > 2. is variable-length null-terminated (\"\\0\") name of a file\n> > or directory, or name of directory where submodule is attached\n> > \n> > 3. is 40-bytes _binary_ identifier.\n> > \n> > HTH\n> \n> It does help, thanks.\n> \n> Though I'm beginning to think we have a crazy object format. Not only do\n> we have a lot of indirections (like ascii representation of decimal\n> representation of length), but we store sha1 as ascii in commit and tag\n> objects and as binary in tree objects. Which makes tree objects the only\n> unpleasant ones to look at (and parse) in raw form. (I was hoping we can\n> dispose of/deprecate cat-file -p in favor of show). Oh well.\n\nWell, actually we have pretty consistent format, i.e. we use textual\nformat everywhere (textual size of blob instead of some variable-length\ninteger, textual name of type of object instead of a byte for it, epoch\nas a text and not 64bit signed int in some network format, hexadecimal sha1,\nspace separated (sub)fields)... \n\n... with the sole exception of tree object, which uses _binary_ sha1.\nWhat was Linus thinking?!?\n\nTo have consistency the tree entry should IMVHO look like this\n\n SPC NUL LF\n\n\nNb. with hexadecimal sha-1 everywhere it would be I think possible (if very\nvery difficult) to move to different hash function: SHA-256, Skein, etc.\nI don't know if it is now at all possible...\n\n-- \nJakub Narebski\nPoland\n"}]}