From: Junio C Hamano <hidden> Date: 2016-06-15 22:58:31
Nicolas Pitre [off-list ref] writes:
On Tue, 27 Aug 2013, Junio C Hamano wrote:
quoted
Nicolas Pitre [off-list ref] writes:
...
quoted
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?"
quoted
quoted
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.
On Tue, Aug 27, 2013 at 11:44 PM, Junio C Hamano [off-list ref] 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. 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? 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.
--
Duy
From: Nicolas Pitre <nico@fluxnic.net> Date: 2016-06-15 22:58:32
On Wed, 28 Aug 2013, Duy Nguyen wrote:
On Tue, Aug 27, 2013 at 11:44 PM, Junio C Hamano [off-list ref] wrote:
quoted
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.
On Wed, Aug 28, 2013 at 9:58 AM, Nicolas Pitre [off-list ref] wrote:
quoted
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.
I use ref-delta as an alternate escape hatch to store missing commits
and trees in unparsed format. In order to do that, I need a base ref
SHA-1 and we can create and store SHA-1 of empty commit and emptry
tree in sha1_file.c (because empty commit is not in a valid format and
can't be parsed and stored in v3). So the result pack is still "thin"
but it should only lack at most two objects: empty commit and empty
tree. Thinking again this is much uglier than escape hatches to v3
tables..
--
Duy