Nicolas Pitre <nico@xxxxxxx> writes: > So let me summarize: > > - the union is a hash. > > - the hash is either an offset value or a sha1 digest. > > - this hash is used for fast object lookup _only_. > > - it does sort differently on big vs little endian machines. > > - but we don't care at all because > > - it is a private algorithmic thing that doesn't "bleed" into any > _real_ data structure, and > > - it doesn't have any influence on the format of the end result. > > - it is only a runtime abstraction and nothing else. > > - It never gets into the pack nor the pack index themselves. > > Do you still have issues with that? The part you pointed out to me about "accidental collision" still bothers me somewhat. Right now we do not produce ref-delta and ofs-delta in the same stream, 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. I am actually Ok if we say the code assumes one stream has only ref-delta or ofs-delta and never both. 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. 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. By the way can we call that find_delta_children() pretty please? - 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