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

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

[Michael J Gruber]

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
---
> tagger Junio C Hamano <gitster@pobox.com> 1317417666 -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

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

[Junio C Hamano]

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

> 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?

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

> I'd suggest
> prettifying dates with "-p" for commit objects also.

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.

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

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 07.10.2011 20:04:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> 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?
> 
> "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).

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'd suggest
>> prettifying dates with "-p" for commit objects also.
> 
> 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.

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

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

[Jakub Narebski]

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

[cut]
> 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.

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 Narębski

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

[Michael J Gruber]

Jakub Narebski venit, vidit, dixit 08.10.2011 01:50:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
> [cut]
>> 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.
> 
> 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

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

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

[Jakub Narebski]

On Sat, 8 Oct 2011, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 08.10.2011 01:50:

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

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

-- 
Jakub Narebski
Poland