Nicolas Pitre <nico@xxxxxxxxxxx> writes: > On Tue, 27 Aug 2013, Junio C Hamano wrote: > >> Nicolas Pitre <nico@xxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html