Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 25 Mar 2007, Shawn O. Pearce wrote: > > > > > > What happens to the paths, that do not have a correponding entry in the > > > path name table, because they are not among the 65535 most frequent > > > paths in the pack? > > > > They don't appear in the table. And any tree that uses them is > > forced to use the "legacy" OBJ_TREE encoding. Which is what we > > have now in pack v2, and in loose objects. > > Would it hurt too much to just make it four bytes, and avoid that issue? > > Special cases - and *especially* special cases that are hard to trigger in > the first place - equal bugs. And bugs are much much worse than trying to > save a little bit of space. Worth exploring. When I get back to rebasing that topic onto Junio's tree I'll try a 4 byte index and see what kind of damage it does on space on large projects (Mozilla, linux-2.6, Eclipse). You may be right, an 8 byte record may just be worth the cost. > > The author_time field is not present if flags & 128 is true. > > If flags & 128 is false, its present, and uses the same encoding > > as commit_time. Why is this field optional? Because its not > > uncommon for it to match commit_time! ;-) > > If the author time is the same as the commit time, most of the time the > author is the same as the committer too, no? So the field should be > conditional not for the author_time, but for the combination, no? Excellent observation. I'll make that change at the same time that I fix the meaning of flags & 128 to mean "more data follows". Thanks! -- Shawn. - 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