Re: [PATCH 00/23] Preliminary pack v4 support
- From
Nicolas Pitre <nico@fluxnic.net>
- Date
- Aug 28, 2013, 02:58 UTC
- Message-ID
- <alpine.LFD.2.03.1308272241470.14472@syhkavp.arg>
- In-Reply-To
- <CACsJy8AttNxePUG9cKw9ihAmRd=kFpcsgwe2yj_FRQbhc-akCg@mail.gmail.com>
On Wed, 28 Aug 2013, Duy Nguyen wrote:
Show 7 quoted lines
> On Tue, Aug 27, 2013 at 11:44 PM, Junio C Hamano <gitster@pobox.com> wrote: > > As you have "0-index" escape hatch for SHA-1 table, but no similar > > escape hatch for the people's name table, I can see why it may be > > cumbersome to fix a thin pack by only appending to a received > > packfile and updating a few header fields, though. > > We also need an escape hatch for path name table.
Well, right. I think this is probably the cleanest solution if we don't want to update the commit/tree dictionary table with new entries (they could simply be appended at the end). That wouldn't work for the SHA1 table though, so perhaps a secondary table for the appended objects could then be carried into the pack index file.
> But what if we store > appended objects in OBJ_REF_DELTA format where base ref is empty > tree/commit and cached by sha1_file.c?
I don't follow you here. Missing objects need to be added to the pack, they can't be cached anywhere.
> We won't need to update > dictionary tables. Parsing is a bit ugly though (e.g. v3 tree with v2 > base) but we have to deal with that anyway because people can have v2 > and v3 packs mixed in.
Absolutely.
Nicolas