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
