Re: t3010 broken by 2eac2a4

> Eric Sunshine <sunshine@sunshineco.com> 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.