Re: [PATCH 00/23] Preliminary pack v4 support

[Junio C Hamano <gitster@pobox.com>]

Nicolas Pitre <nico@fluxnic.net> writes:

> On Tue, 27 Aug 2013, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@fluxnic.net> writes:
>> ... 
>> > I'd like to preserve the author time stamps as they relate to where in
>> > the world I was when the corresponding code was written.  You'll notice
>> > I didn't work on the code in the same order as it is now presented.
>> 
>> We can also notice things like "From: user@machine.(none)" ;-)
>
> Heh.

In any case, the "Date: " in-body header next to your "From: "
in-body header is your friend if you want to do the "where and when
did I work on this?"

>> > Still open question: what to do with a thin pack.  Should we really
>> > complete it with local objects upon reception, or were we only over
>> > paranoid at the time we imposed this rule?
>> 
>> I do not think paranoia had much to do with it.  I am afraid that
>> allowing a delta in a pack to depend on a base in another pack means
>> that the former pack becomes unusable without the latter, which
>> would make object store management (e.g. partial repacking) a lot
>> more cumbersome, no?
>
> That's what I'm wondering.  We already end up with a broken repository 
> if the commit graph is spread across multiple packs and one of those 
> pack is removed.  Having a delta base in a separate pack is not much 
> different in that regard.

In practice, maybe, but I somehow find that it is more fundamental
breakage not to be able to reconstitute objects that a pack and its
index claims to have than missing an object that is referenced in
the reachability graph.

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.

> So the rule could be that any kind of repacking must not carry over 
> deltas with a non local base i.e. repack always produces delta 
> references belonging to the same pack.