All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: How pretty is pretty? git cat-file -p inconsistency
Date: Sat, 8 Oct 2011 18:36:32 +0200	[thread overview]
Message-ID: <201110081836.33941.jnareb@gmail.com> (raw)
In-Reply-To: <4E906292.1020909@drmicha.warpmail.net>

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

      reply	other threads:[~2011-10-08 16:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-07  8:44 How pretty is pretty? git cat-file -p inconsistency Michael J Gruber
2011-10-07 18:04 ` Junio C Hamano
2011-10-07 20:26   ` Michael J Gruber
2011-10-07 23:50     ` Jakub Narebski
2011-10-08 14:47       ` Michael J Gruber
2011-10-08 16:36         ` Jakub Narebski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201110081836.33941.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.