On Tue, 17 Oct 2006, Junio C Hamano wrote: > The part you pointed out to me about "accidental collision" > still bothers me somewhat. I'll try to clear them away. > Right now we do not produce ref-delta and ofs-delta in the same > stream, It is fully supported nevertheless. > but if somebody did so then it would mean a disaster to have an > accidental collision of an 8-byte offset value plus 12-byte traiing > NUL and another base object whose object name happens to match that > pattern. Not really. The only effect that would have on the sorted list of delta entries -- such sorting used to bring all deltas with the same base object contigously -- is that those deltas might not be perfectly contigous wrt their base object. This is why there is a test to skip deltas if they happen not to be of the expected type. > I am actually Ok if we say the code assumes one stream has only > ref-delta or ofs-delta and never both. I'm perfectly OK with both types completely randomized. > But then I suspect the first pass of parse_pack_objects() should > make sure that assumption holds true for the pack being > inspected and barf if it is not. This is an unnecessary restriction though. > Also the second pass do not have to run two find_delta_childs() calls > per delta object because by that time we know which kind would never > appear in the packfile. True, but the flexibility is worth having I think. It makes the thing more robust instead of less. > By the way can we call that find_delta_children() pretty please? I have no problem with that. Nicolas - 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