[RFC] git cat-file "literally" option

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

On 02/18/2015 03:09 PM, karthik nayak 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.

On Wed, Feb 18, 2015 at 7:50 PM, karthik nayak <karthik.188@gmail.com> wrote:

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

On Wed, Feb 18, 2015 at 5:58 AM, Duy Nguyen <pclouds@gmail.com> wrote:

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.

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:

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