Shawn Pearce <spearce@xxxxxxxxxxx> writes: > What I did in fast-import was give inflate whatever was left in > the current mapping; then if I got a Z_OK or Z_BUF_ERROR back from > inflate I move the mapping to the next 128 MiB chunk and reset my > z_stream's next_in/avail_in accordingly, then recall inflate. Makes sense. > But having the length or ending offset in the index will help with > copying the object during a repack as well as prevent us from needing > to guess during accesses. Actually pack-objects already builds the reverse index without the help from the updated .idx file format, so while having it pre-built in .idx may help, it is not necessary for it. With your "feed until the end of the current window and if we need more map in the next window" logic, we do not even need to know the length of each entry at runtime either. So I am inclined to chuck the previous patch that records the next object number in each entry. We could keep the 64-bit offset, which would make an entry to be 28-byte instead of 32-byte. -- VGER BF report: U 0.5 - 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