Taylor Blau <me@xxxxxxxxxxxx> writes: >> So when you pick the copy of Y out of another pack, what's so >> different? After emitting Y to the resulting pack stream (and >> remembering where in the packstream you did so), when it is X's turn >> to be emitted, shouldn't you be able to compute the distance in the >> resulting packstream to represent X as an ofs-delta against Y, which >> should already be happening when you had both X and Y in the same >> original pack? > > Good question. The difference is that if you're reusing X and Y from > same pack, you know that Y occurs some number of bytes *before* X in the > resulting pack. > > But if Y comes from a different pack, it may get pushed further back in > the MIDX pseudo-pack order. So in that case the assembled pack may list > X before Y, in which case X cannot be an OFS_DELTA of Y, since offset > deltas require that the base object appears first. That is what we have always done even before we started bitmap based optimization. If we happen to write Y before X, we consider doing ofs-delta for X, but otherwise we do ref-delta for X. We do reorder fairly late in the pipeline when we notice that X that we are about to write out depends on Y that we haven't emitted to avoid this, though. All of that the bitmap-based optimization code path should be able to imitate, I would think.
