{"thread":{"id":"38586","subject":"[RFC] git cat-file \"literally\" option","startedAt":"2015-02-18T09:39:35Z","lastAt":"2015-02-19T10:10:52Z","messageCount":5,"participants":["karthik nayak","Duy Nguyen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"256262","messageId":"54E45DD7.205@gmail.com","threadId":"38586","inReplyTo":null,"subject":"[RFC] git cat-file \"literally\" option","fromName":"karthik nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2015-02-18T09:39:35Z","receivedAt":"2015-02-18T09:39:35Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"Hey,\nAfter reading http://thread.gmane.org/gmane.comp.version-control.git/256878\nI have started working on the git cat file --literally option.\n\nI'm wondering if I should implement it as an add on to the existing options,\nwherein we could say \"git cat-file (t | -s | -e | -p | | \n--texconv) --literally \"\nso that it would be able to print the required data literally or should \nI implement it such that\nwe could say \"git cat-file (-t | -s | -e | -p | | --texconv | \n--literally) \"\nso it would just give all information about the given object. (Maybe \nlike the -p option?)\n\nFor example :\nif I create a bogus object like\n\ngit hash-object -t bogus --literally -w --stdin Hey,\n> After reading \n> http://thread.gmane.org/gmane.comp.version-control.git/256878\n> I have started working on the git cat file --literally option.\n>\n> I'm wondering if I should implement it as an add on to the existing \n> options,\n> wherein we could say \"git cat-file (t | -s | -e | -p | | \n> --texconv) --literally \"\n> so that it would be able to print the required data literally or \n> should I implement it such that\n> we could say \"git cat-file (-t | -s | -e | -p | | --texconv | \n> --literally) \"\n> so it would just give all information about the given object. (Maybe \n> like the -p option?)\n>\n> For example :\n> if I create a bogus object like\n>\n> git hash-object -t bogus --literally -w --stdin \n> Should I implement\n> git cat-file -t --literally 49993fe130c4b3bf24857a15d7969c396b7bc187\n> or should I implement\n> git cat-file --literally 49993fe130c4b3bf24857a15d7969c396b7bc187\n> To get information pertaining to the object \"bogus:.\n>\n>\n> What do you people think?\n> Thanks\n> -Karthik\nAlso,\nIs there any way I can get the type of object made via git hash-object \n--literally. The problem I'm facing is \"sha1_object_info()\" returns a \nobject_type enum, so objects not specified there are considered as errors.\n"},{"id":"256268","messageId":"CACsJy8BJnHTyXhhJaCuZAzjm=Gd96EjANEw76j=3L92cmbX7HA@mail.gmail.com","threadId":"38586","inReplyTo":"54E48A96.8010301@gmail.com","subject":"Re: [RFC] git cat-file \"literally\" option","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-02-18T13:58:01Z","receivedAt":"2015-02-18T13:58:01Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 18, 2015 at 7:50 PM, karthik nayak wrote:\n> Also,\n> Is there any way I can get the type of object made via git hash-object\n> --literally. The problem I'm facing is \"sha1_object_info()\" returns a\n> object_type enum, so objects not specified there are considered as errors.\n\nUse what sha1_object_info() uses behind the scene. Loose object\nencodes object type as a string, you could just print that string and\nskip the enum object_type conversion. You probably need special\ntreatment for packed objects too. See parse_sha1_header() and\nunpack_object_header().\n-- \nDuy\n"},{"id":"256275","messageId":"CAPc5daUWTRA=cziUsXEbwNrggA_3mhRsrfnVaQ-F7iEeSO7ATw@mail.gmail.com","threadId":"38586","inReplyTo":"CACsJy8BJnHTyXhhJaCuZAzjm=Gd96EjANEw76j=3L92cmbX7HA@mail.gmail.com","subject":"Re: [RFC] git cat-file \"literally\" option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-18T15:47:25Z","receivedAt":"2015-02-18T15:47:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Wed, Feb 18, 2015 at 5:58 AM, Duy Nguyen wrote:\n> ... skip the enum object_type conversion. You probably need special\n> treatment for packed objects too.\n\nI do not think you can store object of type \"bogus\" in a pack data stream\nto begin with, so I wouldn't worry about packed objects.\n\n\"cat-file --literally\" that does not take \"-t\" would not be useful, as the\noutput \"cat-file \" does not tell what the thing\nis. Other things like sizes and existence can be inferred once you have\nan interface to do \"cat-file \", so in that sense -e and -s\nare not essential (this also applies to \"cat-file\" without --literally).\n\nBy definition, \"--literally -p\" would not be able to do anything fancier than\njust dump the bytes (i.e. what \"cat-file \" does), as the\nbogus type is not something the code would know the best external\nrepresentation for.\n"},{"id":"256338","messageId":"54E5B6AC.3030706@gmail.com","threadId":"38586","inReplyTo":"CAPc5daUWTRA=cziUsXEbwNrggA_3mhRsrfnVaQ-F7iEeSO7ATw@mail.gmail.com","subject":"Re: [RFC] git cat-file \"literally\" option","fromName":"karthik nayak","fromEmail":"karthik.188@gmail.com","sentAt":"2015-02-19T10:10:52Z","receivedAt":"2015-02-19T10:10:52Z","isPatch":false,"sender":{"key":"karthik.188@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1786334?v=4"},"body":"\nOn 02/18/2015 07:28 PM, Duy Nguyen wrote:> On Wed, Feb 18, 2015 at 7:50\n > Use what sha1_object_info() uses behind the scene. Loose object\n > encodes object type as a string, you could just print that string and\n > skip the enum object_type conversion. You probably need special\n > treatment for packed objects too. See parse_sha1_header() and\n > unpack_object_header().\n\nThank you will look into that!\n\nOn 02/18/2015 09:17 PM, Junio C Hamano wrote:\n> On Wed, Feb 18, 2015 at 5:58 AM, Duy Nguyen wrote:\n>> ... skip the enum object_type conversion. You probably need special\n>> treatment for packed objects too.\n>\n> I do not think you can store object of type \"bogus\" in a pack data stream\n> to begin with, so I wouldn't worry about packed objects.\n>\n> \"cat-file --literally\" that does not take \"-t\" would not be useful, as the\n> output \"cat-file \" does not tell what the thing\n> is. Other things like sizes and existence can be inferred once you have\n> an interface to do \"cat-file \", so in that sense -e and -s\n> are not essential (this also applies to \"cat-file\" without --literally).\n>\n> By definition, \"--literally -p\" would not be able to do anything fancier than\n> just dump the bytes (i.e. what \"cat-file \" does), as the\n> bogus type is not something the code would know the best external\n> representation for.\n>\n\nThanks for clearing that out. Will work on this for now.\n"}]}