On Wed, 28 Aug 2013, Duy Nguyen wrote:

> On Tue, Aug 27, 2013 at 11:44 PM, Junio C Hamano <gits...@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.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to