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

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