Re: t3010 broken by 2eac2a4

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 22, 2013, 21:16 UTC
Message-ID: <xmqqbo4pqvde.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAPig+cQHTvmTWvGfg1Z3KfBrPD+QbSEbYBYz6XWT3KKu3-+jyQ@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 5 quoted lines

> 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.