While (hopefully) I have your attention, I have another question
about the recent optimization.
commit cf558704fb68514a820e3666968967c900e0fd29
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Create pathname-based hash-table lookup into index
diff --git a/dir.c b/dir.c
index 1b9cc7a..6543105 100644
--- a/dir.c
+++ b/dir.c
@@ -346,7 +346,7 @@ static struct dir_entry *dir_entry_new(cons...
struct dir_entry *dir_add_name(struct dir_struct *dir, const c...
{
- if (cache_name_pos(pathname, len) >= 0)
+ if (cache_name_exists(pathname, len))
return NULL;
ALLOC_GROW(dir->entries, dir->nr+1, dir->alloc);
This used to check if there is a stage#0 entry of that name in
the index. But the name-hash based index look-up does not care
about the stage as far as I can tell.
I haven't managed to come up with a failure case to demonstrate,
but I think this can affect ls-files and clean, potentially in a
bad way. "git add dir/" to resolve unmerged paths under dir/
somewhere should not be affected, as the codepath calls
read_directory() before reading the cache (so the check will
always say "Nope, we do not have such a path in the index yet").
I am not sure what the right solution would be. The motivation
for the patch was to make "does this name exist in the index"
and also "does this exist under an equivalent name" efficient,
but it is asking a question that is not precise enough. Are we
interested in such an entry at any stage, or only at stage#0, or
what?
This could be related to the recent "status segfaults, bisected
to cf558704" issue posted to the list. I dunno.
-
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
