Jeff King <peff@xxxxxxxx> writes: > ... Things may have changed since then, of course, but I at > least know that they were sufficient in 34110cd^. Looking at where cache_tree_free() is called, I think back then the two-way merge was deemed OK, but we did not trust three-way merge or merge-recursive at all. > I think you can construct two tests that will both work in the "ideal" > case. In the first one, you move to a tree that updates "foo", and > therefore the root cache-tree is invalidated. I have to warn you that under-invalidation of cache-tree is extremely hard to find. The only way I know, which I had to resort to when dealing with a handful of instances of under-invalidation bugs, is to run write-tree with potentially corrupt cache-tree and then using the same index but with the cache-tree purged, run another write-tree and check to see if two trees match. > In general, t0090 could benefit from using a larger tree. For example, > the add test does "git add foo" and checks that the root cache-tree was > invalidated. But it should _also_ check that the cache-tree for a > subdirectory is _not_ invalidated (and it isn't; git-add does the right > thing). It is OK to check that we do not over-invalidate for performance, but it is a lot more important to make sure we do not under-invalidate for correctness. I am a bit worried that you seem to be putting more stress on the former. -- 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