Re: [GSoC] Designing a faster index format - Progress report

> On Sun, May 27, 2012 at 4:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Thomas Gummerer <t.gummerer@gmail.com> writes:
> >
> >>> No, read_index_from would go through the normal tree->list conversion.
> >>> What I'd like to see is what it looks like when a command accesses
> >>> index v5 directly in tree form, taking all advantages that tree-form
> >>> provides, and how we should deal with old index versions while still
> >>> supporting index v5 (without losing tree advantages)
> >>
> >> Ah ok, thanks for the clarification, I understand what you meant now.
> >> I think however, that it's not very beneficial to do this conversion
> >> now. git ls-files needs the whole index file anyway, so it's probably
> >> not a very good test.
> >
> > Think about "git ls-files t/" and "git ls-files -u".
> 
> Or harder things like "ls-files -- 't/*.sh'"
> 
> > The former obviously does *not* have to look at the whole thing, even
> > though the current code assumes the in-core data structure that has the
> > whole thing in a flat array.  IIRC, you had unmerged entries tucked at the
> > end outside the main index data, so the latter is also an interesting
> > demonstration of how wonderful the new data format could be.
> 
> and "ls-files -uc" can show how you combine unmerged entries back.
> There's also entry existence check deep in "ls-files -o" that you can
> show how good bsearch on trees is, though that might be going too far
> for an experiment because the call chain is really deep, way outside
> ls-files.c:
> 
> show_files (builtin/ls-files.c)
>  fill_directory (dir.c)
>   read_directory
>    read_directory_recursive
>     treat_path
>      treat_one_path
>       treat_directory
>        directory_exists_in_index
>         cache_pos_name (read-cache.c)
> 
> I just want to make sure that by exercising the new format with some
> real problems, we are certain we don't overlook anything in designing
> the format (or else could be fixed before finalizing it).