Re: t3010 broken by 2eac2a4

Eric Sunshine [off-list ref] writes:

I can confirm this failure on OS X, however, I am somewhat confused by
the follow-up t3010 changes in 3c56875176390eee. Are the t3010 changes
supposed to fail without 2eac2a4cc4bdc8d7 applied? For me, on Linux,
the tests succeed whether 2eac2a4cc4bdc8d7 is applied or not. On OS X,
the tests succeed without 2eac2a4cc4bdc8d7 but fail with it applied.

The 2eac2a4c (ls-files -k: a directory only can be killed if the
index has a non-directory, 2013-08-15) is NOT a correctness fix.

It is an optimization to avoid scanning directories that are known
not to be killed when "ls-files -k" is asked to list killed
paths. The original code without the patch is correct already; it
just is too inefficient because it scans all the directories.  It is
not surprising if the test added by 3c568751 (t3010: update to
demonstrate "ls-files -k" optimization pitfalls, 2013-08-15) passes
without 2eac2a4c.

As its log message explains, 3c568751 (t3010: update to demonstrate
"ls-files -k" optimization pitfalls, 2013-08-15) is to catch a case
where an earlier "something like this" patch (which is the draft for
2eac2a4c) posted to the list would have broken.  That draft patch
was correct only for the case where the top-level directory is
killed, but was broken when a subdirectory (e.g. pathx/ju) is
killed.

On Thu, Aug 22, 2013 at 5:16 PM, Junio C Hamano [off-list ref] wrote:

Eric Sunshine [off-list ref] writes:

quoted

I can confirm this failure on OS X, however, I am somewhat confused by
the follow-up t3010 changes in 3c56875176390eee. Are the t3010 changes
supposed to fail without 2eac2a4cc4bdc8d7 applied? For me, on Linux,
the tests succeed whether 2eac2a4cc4bdc8d7 is applied or not. On OS X,
the tests succeed without 2eac2a4cc4bdc8d7 but fail with it applied.

The 2eac2a4c (ls-files -k: a directory only can be killed if the
index has a non-directory, 2013-08-15) is NOT a correctness fix.

It is an optimization to avoid scanning directories that are known
not to be killed when "ls-files -k" is asked to list killed
paths. The original code without the patch is correct already; it
just is too inefficient because it scans all the directories.  It is
not surprising if the test added by 3c568751 (t3010: update to
demonstrate "ls-files -k" optimization pitfalls, 2013-08-15) passes
without 2eac2a4c.

As its log message explains, 3c568751 (t3010: update to demonstrate
"ls-files -k" optimization pitfalls, 2013-08-15) is to catch a case
where an earlier "something like this" patch (which is the draft for
2eac2a4c) posted to the list would have broken.  That draft patch
was correct only for the case where the top-level directory is
killed, but was broken when a subdirectory (e.g. pathx/ju) is
killed.

Thanks for the explanation.