From: "Shawn O. Pearce" <spearce@spearce.org>
To: Josh Triplett <josh@freedesktop.org>, Jamey Sharp <jamey@minilop.net>
Cc: Jan Hudec <bulb@ucw.cz>, "Stephen R. van den Berg" <srb@cuci.nl>,
Junio C Hamano <gitster@pobox.com>,
david@lang.hm, Scott Chacon <schacon@gmail.com>,
git@vger.kernel.org
Subject: Re: [RFC] Plumbing-only support for storing object metadata
Date: Sun, 17 Aug 2008 23:12:36 -0700 [thread overview]
Message-ID: <20080818061236.GF7376@spearce.org> (raw)
In-Reply-To: <20080816062130.GA4554@oh.minilop.net>
Josh Triplett <josh@freedesktop.org>, Jamey Sharp <jamey@minilop.net> wrote:
> On Sat, Aug 09, 2008 at 08:51:01PM -0700, Shawn O. Pearce wrote:
> > Nico and I have (at least in the past) agreed that type 0 is meant
> > as an escape indicator. If the type is set to 0 then the real type
> > code appears in another byte of data which follows the object's
> > inflated length.
> >
> > That leaves only type 5 available.
> [...]
> > So yea, there really aren't any new type bits available.
>
> If consensus opinion was that new object types were a reasonable way to
> solve this problem, then it sounds as if there's plenty of room to
> create new types using this escape mechanism.
Yes, but we'd hate to see the majority of the encodings within a
pack using the escape mechanism.
So a lot of my argument here was just trying to point out that
type bits aren't free, and we need to make sure the limited ones
available are applied to the majority of the pack contents.
Adding a new type bit is a lot more than just adding it to the pack
data field. Look at the amount of code that needed to be changed to
support gitlink in trees, and that was "reusing" the OBJ_COMMIT type.
Anytime you start poking at the core object enumeration code with
new cases there's a lot of corners that are affected.
--
Shawn.
next prev parent reply other threads:[~2008-08-18 6:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-09 21:07 [RFC] Plumbing-only support for storing object metadata Jamey Sharp, Josh Triplett
2008-08-09 21:49 ` Scott Chacon
2008-08-10 3:51 ` Shawn O. Pearce
2008-08-10 11:20 ` Stephen R. van den Berg
2008-08-10 12:16 ` david
2008-08-10 14:50 ` Jan Hudec
2008-08-10 17:57 ` Stephen R. van den Berg
2008-08-10 18:11 ` Jan Hudec
2008-08-10 20:16 ` Stephen R. van den Berg
2008-08-10 22:34 ` Junio C Hamano
2008-08-10 23:10 ` david
2008-08-11 10:11 ` Stephen R. van den Berg
2008-08-10 11:09 ` Jan Hudec
2008-08-16 6:21 ` Josh Triplett, Jamey Sharp
2008-08-16 7:56 ` david
2008-08-16 9:55 ` Junio C Hamano
2008-08-16 15:07 ` Jan Hudec
2008-08-18 6:12 ` Shawn O. Pearce [this message]
2008-08-18 23:06 ` Derek Fawcus
2008-08-18 23:18 ` Shawn O. Pearce
2008-08-18 23:23 ` Marcus Griep
2008-08-18 23:28 ` Shawn O. Pearce
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=20080818061236.GF7376@spearce.org \
--to=spearce@spearce.org \
--cc=bulb@ucw.cz \
--cc=david@lang.hm \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jamey@minilop.net \
--cc=josh@freedesktop.org \
--cc=schacon@gmail.com \
--cc=srb@cuci.nl \
/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.