On 05/27, Nguyen Thai Ngoc Duy wrote: > On Sun, May 27, 2012 at 4:27 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Thomas Gummerer <t.gummerer@xxxxxxxxx> 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). Ok, that makes sense. I just thought of git ls-files alone, for which it wouldn't make a lot of sense. I'll try implementing this as next step. -- 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