From: karthik nayak <karthik.188@gmail.com>
Date: Thu, 19 Feb 2015 10:10:52 GMT
Subject: Re: [RFC] git cat-file "literally" option
Message-ID: <54E5B6AC.3030706@gmail.com>
In-Reply-To: <CAPc5daUWTRA=cziUsXEbwNrggA_3mhRsrfnVaQ-F7iEeSO7ATw@mail.gmail.com>


On 02/18/2015 07:28 PM, Duy Nguyen wrote:> On Wed, Feb 18, 2015 at 7:50
 > Use what sha1_object_info() uses behind the scene. Loose object
 > encodes object type as a string, you could just print that string and
 > skip the enum object_type conversion. You probably need special
 > treatment for packed objects too. See parse_sha1_header() and
 > unpack_object_header().

Thank you will look into that!

On 02/18/2015 09:17 PM, Junio C Hamano wrote:
> On Wed, Feb 18, 2015 at 5:58 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> ... skip the enum object_type conversion. You probably need special
>> treatment for packed objects too.
>
> I do not think you can store object of type "bogus" in a pack data stream
> to begin with, so I wouldn't worry about packed objects.
>
> "cat-file --literally" that does not take "-t" would not be useful, as the
> output "cat-file <type> <object>" does not tell what <type> the thing
> is. Other things like sizes and existence can be inferred once you have
> an interface to do "cat-file <type> <object>", so in that sense -e and -s
> are not essential (this also applies to "cat-file" without --literally).
>
> By definition, "--literally -p" would not be able to do anything fancier than
> just dump the bytes (i.e. what "cat-file <type> <object>" does), as the
> bogus type is not something the code would know the best external
> representation for.
>

Thanks for clearing that out. Will work on this for now.