How pretty is pretty? git cat-file -p inconsistency

diff <(git cat-file -p tags/v1.7.7) <(git cat-file tag tags/v1.7.7) 4c4 < tagger Junio C Hamano <gitster@pobox.com> Fri Sep 30 14:21:06 2011 -0700 ---

vs.

diff <(git cat-file -p tags/v1.7.7^{}) <(git cat-file commit tags/v1.7.7^{})

(no diff)

That is, "cat file -p" pretty prints dates for tag objects but not for commit objects. In fact, "-p" on commit objects does not prettify at all compared to the raw content. Is that intentional? I'd suggest prettifying dates with "-p" for commit objects also. But just how plumbing is the "-p" mode of "cat-file"?

Michael

Michael J Gruber <git@drmicha.warpmail.net> writes:

"cat-file -p" is an ill-conceived half-ass afterthought, and I do not think anybody sane considers it as part of the "plumbing" ultra stable interface for machine consumption. See a0f15fa (Pretty-print tagger dates., 2006-03-01).

Please make it so. It is your choice to do a patch to update this single thing first, or to discuss the output with "-p" for all the other object types at the same time to get the list concensus before proceeding.

Thanks.

Junio C Hamano venit, vidit, dixit 07.10.2011 20:04:

Uh, I see. "git cat-file -p tagname" is a bit like the the missing "git tag show tagname" or "git show tagname" without the commit.

I never knew how ugly the output of "git tag-file tree sha1" is. I guess it's the type of object whose format I don't know... We don't have an object format description in Doc/technical, do we? tree.c doesn't tell me much.

Looking at how "cat-file -p" for tags is done makes me not want to do it for commits ;) We do have pretty "git show" for all types of objects, though "git cat-file -p treeobject" is more informative than "git show treeobject". I guess I have to make up my mind about what direction to go.

Michael

Michael J Gruber <git@drmicha.warpmail.net> writes:

[cut]

I had to handle this in my attempt to write "git blame <directory>" in Perl, which was using `git cat-file --batch`, and that gives raw data and not pretty-printed.

Tree object consist of zero or more entries. Each item consist of mode, filename, and sha1:

  <mode> SPC <filename> NUL <sha1>

where

1. <mode> is variable-length (!) text (!) containing mode of an
   entry. It encodes type of entry: if it is blob (including special
   case: symbolic link), tree i.e. directory, or a commit
   i.e. submodule.  Does not include leading zeros.

2. <filename> is variable-length null-terminated ("\0") name of a file
   or directory, or name of directory where submodule is attached

3. <sha1> is 40-bytes _binary_ identifier.

HTH

Jakub Narebski venit, vidit, dixit 08.10.2011 01:50:

It does help, thanks.

Though I'm beginning to think we have a crazy object format. Not only do we have a lot of indirections (like ascii representation of decimal representation of length), but we store sha1 as ascii in commit and tag objects and as binary in tree objects. Which makes tree objects the only unpleasant ones to look at (and parse) in raw form. (I was hoping we can dispose of/deprecate cat-file -p in favor of show). Oh well.

Michael

On Sat, 8 Oct 2011, Michael J Gruber wrote:

Well, actually we have pretty consistent format, i.e. we use textual format everywhere (textual size of blob instead of some variable-length integer, textual name of type of object instead of a byte for it, epoch as a text and not 64bit signed int in some network format, hexadecimal sha1, space separated (sub)fields)...

... with the sole exception of tree object, which uses _binary_ sha1. What was Linus thinking?!?

To have consistency the tree entry should IMVHO look like this

  <textual mode> SPC <filename> NUL <hexadecimal sha1> LF

Nb. with hexadecimal sha-1 everywhere it would be I think possible (if very very difficult) to move to different hash function: SHA-256, Skein, etc. I don't know if it is now at all possible...