From: Junio C Hamano <gitster@pobox.com>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: Duy Nguyen <pclouds@gmail.com>, Git Mailing List <git@vger.kernel.org>
Subject: Re: pack v4 trees with a canonical base
Date: Tue, 10 Sep 2013 13:45:44 -0700 [thread overview]
Message-ID: <xmqq38pcxv5z.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <alpine.LFD.2.03.1309101615080.20709@syhkavp.arg> (Nicolas Pitre's message of "Tue, 10 Sep 2013 16:17:27 -0400 (EDT)")
Nicolas Pitre <nico@fluxnic.net> writes:
very much appreciated to> On Tue, 10 Sep 2013, Junio C Hamano wrote:
>
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>> > On Tue, Sep 10, 2013 at 2:25 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> >> An eventual optimization to index-pack when completing a pack would be
>> >> to attempt the encoding of appended tree objects into the packv4 format
>> >> using the existing dictionary table in the pack, and fall back to the
>> >> canonical format if that table doesn't have all the necessary elements.
>> >
>> > Yeah, it's on the improvement todo list. The way pack-objects creates
>> > dictionaries right now, the tree dict should contain all elements the
>> > base trees need so fall back is only necessary when trees are have
>> > extra zeros in mode field.
>>
>> Careful.
>>
>> There may be trees in the wild that record 100775 or 100777 in the
>> mode field for executable blobs, which also need to be special
>> cased.
>
> All the file mode bits are always preserved. So this is not really a
> special case as far as the pack v4 encoding is concerned.
Ahh. OK. It can theoretically be argued that you could further
squeeze 13 bits out per tree entry because you would need only 5
possible values (100644, 100755 120000, 40000, and 160000, all
octal) for the modes, but we will never know what other modes we
would want to use in the future, so not being over-tight and using
16-bit for this purpose is probably a good trade-off (squeezing 8
bits out per tree entry would make the shape of ident table entry
and tree path entry different and may hurt reusing the code to parse
these tables).
next prev parent reply other threads:[~2013-09-10 20:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-09 19:25 pack v4 trees with a canonical base Nicolas Pitre
2013-09-10 0:52 ` Duy Nguyen
2013-09-10 20:13 ` Junio C Hamano
2013-09-10 20:17 ` Nicolas Pitre
2013-09-10 20:45 ` Junio C Hamano [this message]
2013-09-10 21:03 ` Nicolas Pitre
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=xmqq38pcxv5z.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=pclouds@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).