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

[Thomas Gummerer <t.gummerer@gmail.com>]

On 05/26, Nguyen Thai Ngoc Duy wrote:
> On Sat, May 26, 2012 at 3:15 AM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> > On 05/25, Nguyen Thai Ngoc Duy wrote:
> >> On Wed, May 23, 2012 at 7:21 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:
> >> > == Outlook for the next week ==
> >> >
> >> > - Start working on actual git code
> >> > - Read the header of the new format
> >>
> >> I know it's out of scope, but it would be great if you could make
> >> ls-files read the new index format directly. Having something that
> >> actual works will ensure we don't overlook anything in the new format.
> >> We can then learn from ls-files lesson (especially how to handle both
> >> new/old format) and come up with api/in-core structures for the rest
> >> of git later.
> >
> > Thanks for your suggestion. How did you think this should be done?
> > Writing a extra function in ls-files, just for outputting? I don't
> > think it is necessary to write a extra function, since the result
> > from the read_index_from function in read-cache is used for that
> > anyway. Or did you have something different in mind, that I'm missing
> > here?
> 
> 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.