Jeff King <peff@xxxxxxxx> writes:
> I still think replaying real-world test cases is going to be more likely
> to find issues in invalidation.
Yes, but it depends on what kind of replaying you have in mind. It is
very hard to come up with "replaying real-world test case".
For example, randomly picking commit pair <$A,$B> from the kernel
repository and running
git reset --hard $A
git checkout $B
T0=$(git write-tree)
drop-cache-tree
T1=$(git write-tree)
test "$T0" = "$T1" && test "$T0" = $(git rev-parse $B^{tree})
is necessary but I do not think that is sufficient. We also want to do
something like:
git reset --hard $A
... modify paths that do not change between $A and $B
... git add these paths
git write-tree
git checkout $B
with and without the "git write-tree" to see the part of the cache-tree
smudged by the modification behaves sanely. The codepath that is used
to deal with the case where the index does not match $A but matches $B is
also different, so the "modify path and git add" step would have to be
crafted carefully to touch all bases.
--
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