# [RFC] git cat-file "literally" option

5 messages from 2015-02-18 to 2015-02-19. Participants: karthik nayak, Duy Nguyen, Junio C Hamano.
Thread: https://gitlist.dev/t/38586

## karthik nayak, 2015-02-18 09:39

Subject: [RFC] git cat-file "literally" option
Message-ID: <54E45DD7.205@gmail.com>
URL: https://gitlist.dev/e/54E45DD7.205%40gmail.com

```
Hey,
After reading http://thread.gmane.org/gmane.comp.version-control.git/256878
I have started working on the git cat file --literally option.

I'm wondering if I should implement it as an add on to the existing options,
wherein we could say "git cat-file (t | -s | -e | -p | <type> | 
--texconv) --literally <object>"
so that it would be able to print the required data literally or should 
I implement it such that
we could say "git cat-file (-t | -s | -e | -p | <type> | --texconv | 
--literally) <object>"
so it would just give all information about the given object. (Maybe 
like the -p option?)

For example :
if  I create a bogus object like

git hash-object -t bogus --literally -w --stdin </dev/null

Should I implement
git cat-file -t --literally 49993fe130c4b3bf24857a15d7969c396b7bc187
or should I implement
git cat-file --literally 49993fe130c4b3bf24857a15d7969c396b7bc187
To get information pertaining to the object "bogus:.


What do you people think?
Thanks
-Karthik

```

## karthik nayak, 2015-02-18 12:50

Subject: Re: [RFC] git cat-file "literally" option
Message-ID: <54E48A96.8010301@gmail.com>
URL: https://gitlist.dev/e/54E48A96.8010301%40gmail.com
In-Reply-To: <54E45DD7.205@gmail.com>

```

On 02/18/2015 03:09 PM, karthik nayak wrote:
> Hey,
> After reading 
> http://thread.gmane.org/gmane.comp.version-control.git/256878
> I have started working on the git cat file --literally option.
>
> I'm wondering if I should implement it as an add on to the existing 
> options,
> wherein we could say "git cat-file (t | -s | -e | -p | <type> | 
> --texconv) --literally <object>"
> so that it would be able to print the required data literally or 
> should I implement it such that
> we could say "git cat-file (-t | -s | -e | -p | <type> | --texconv | 
> --literally) <object>"
> so it would just give all information about the given object. (Maybe 
> like the -p option?)
>
> For example :
> if  I create a bogus object like
>
> git hash-object -t bogus --literally -w --stdin </dev/null
>
> Should I implement
> git cat-file -t --literally 49993fe130c4b3bf24857a15d7969c396b7bc187
> or should I implement
> git cat-file --literally 49993fe130c4b3bf24857a15d7969c396b7bc187
> To get information pertaining to the object "bogus:.
>
>
> What do you people think?
> Thanks
> -Karthik
Also,
Is there any way I can get the type of object made via git hash-object 
--literally. The problem I'm facing is "sha1_object_info()" returns a 
object_type enum, so objects not specified there are considered as errors.

```

## Duy Nguyen, 2015-02-18 13:58

Subject: Re: [RFC] git cat-file "literally" option
Message-ID: <CACsJy8BJnHTyXhhJaCuZAzjm=Gd96EjANEw76j=3L92cmbX7HA@mail.gmail.com>
URL: https://gitlist.dev/e/CACsJy8BJnHTyXhhJaCuZAzjm%3DGd96EjANEw76j%3D3L92cmbX7HA%40mail.gmail.com
In-Reply-To: <54E48A96.8010301@gmail.com>

```
On Wed, Feb 18, 2015 at 7:50 PM, karthik nayak <karthik.188@gmail.com> wrote:
> Also,
> Is there any way I can get the type of object made via git hash-object
> --literally. The problem I'm facing is "sha1_object_info()" returns a
> object_type enum, so objects not specified there are considered as errors.

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().
-- 
Duy

```

## Junio C Hamano, 2015-02-18 15:47

Subject: Re: [RFC] git cat-file "literally" option
Message-ID: <CAPc5daUWTRA=cziUsXEbwNrggA_3mhRsrfnVaQ-F7iEeSO7ATw@mail.gmail.com>
URL: https://gitlist.dev/e/CAPc5daUWTRA%3DcziUsXEbwNrggA_3mhRsrfnVaQ-F7iEeSO7ATw%40mail.gmail.com
In-Reply-To: <CACsJy8BJnHTyXhhJaCuZAzjm=Gd96EjANEw76j=3L92cmbX7HA@mail.gmail.com>

```
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.

```

## karthik nayak, 2015-02-19 10:10

Subject: Re: [RFC] git cat-file "literally" option
Message-ID: <54E5B6AC.3030706@gmail.com>
URL: https://gitlist.dev/e/54E5B6AC.3030706%40gmail.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.

```