On Thu, Aug 22, 2013 at 5:16 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Eric Sunshine <sunsh...@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.

Thanks for the explanation.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to