Re: Understanding version 4 packs

["Shawn O. Pearce" <spearce@spearce.org>]

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> So what you will find is that the EXTOBJ_FILENAME_TABLE is dumped
> out behind all of the commits, but before the first OBJ_DICT_TREE,
> and since all trees tend to get converted to an OBJ_DICT_TREE,
> the EXTOBJ_FILENAME_TABLE is sandwiched exactly between the commits
> and the trees.
...
> The reason we put the EXTOBJ_FILENAME_TABLE behind the commits is
> we often walk the commit chains (following parent pointers) without
> looking at the trees at all.  Consider `git log`, in the default
> settings we don't need the trees.  By keeping the filename table
> behind the commits the OS read-ahead buffering gets a better chance
> at loading all of the data we need, and none of the data we don't.
> 
> So that's why its where it is.

I just talked with Junio about this on #git.

My real reason for putting the EXTOBJ_FILENAME_TABLE here is
"lack of a better reason".  I just didn't write that above.  ;-)

We want it before the first OBJ_DICT_TREE to help the unpackers.

And just like we don't currently ever store the delta base for an
OBJ_TREE before the first commit (as commits always get packed first)
we also don't store the EXTOBJ_FILENAME_TREE before the first commit.

Junio raised the point that in large projects `git log -- asm/i386`
can be a very common/useful/necessary operation, and that in such
cases we need to evaluate trees as part of the log operation.
Any attempt to optimize for git-log without a path spec is wrong,
wrong, wrong.  I agree.

The part I quoted above was not trying to imply that Nico and I
are optimizing for using git-log without a path limiter.  It just
read that way to Junio, and may read that way for others too.
Hence this follow-up.

I'm open to suggestions about placement for EXTOBJ_FILENAME_TABLE,
but I think its current position between commits and trees is the
probably the best we can get.

-- 
Shawn.