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

Michael J Gruber [off-list ref] 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.

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

Michael J Gruber [off-list ref] writes:

quoted

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.

quoted

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

Michael J Gruber [off-list ref] 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

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

Michael J Gruber [off-list ref] writes:

[cut]

quoted

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

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

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

quoted

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