Thomas Gummerer [off-list ref] writes:
quoted
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".
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.
Unlike other commands like status and diff that may need to look at things
other than the index, the core functionalitly of ls-files is purely about
the index. I do not understand why you think it is not a good test case.
If an updated index structure cannot even improve ls-files, there is no
hope it can improve other more complex commands that need to walk the
index and something else in parallel.
On Sun, May 27, 2012 at 4:27 PM, Junio C Hamano [off-list ref] wrote:
Thomas Gummerer [off-list ref] writes:
quoted
quoted
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).
--
Duy
On 05/27, Nguyen Thai Ngoc Duy wrote:
On Sun, May 27, 2012 at 4:27 PM, Junio C Hamano [off-list ref] wrote:
quoted
Thomas Gummerer [off-list ref] writes:
quoted
quoted
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'"
quoted
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.