From: Junio C Hamano <gitster@pobox•com>
To: Eric Sunshine <sunshine@sunshineco•com>
Cc: Brian Gernhardt <brian@gernhardtsoftware•com>,
"git\@vger.kernel.org List" <git@vger•kernel.org>
Subject: Re: t3010 broken by 2eac2a4
Date: Thu, 22 Aug 2013 14:16:29 -0700 [thread overview]
Message-ID: <xmqqbo4pqvde.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAPig+cQHTvmTWvGfg1Z3KfBrPD+QbSEbYBYz6XWT3KKu3-+jyQ@mail.gmail.com> (Eric Sunshine's message of "Thu, 22 Aug 2013 16:54:10 -0400")
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.
next prev parent reply other threads:[~2013-08-22 21:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-21 20:31 t3010 broken by 2eac2a4 Brian Gernhardt
2013-08-21 21:41 ` Junio C Hamano
2013-08-22 20:54 ` Eric Sunshine
2013-08-22 21:16 ` Junio C Hamano [this message]
2013-08-22 21:22 ` Eric Sunshine
2013-08-22 21:32 ` Junio C Hamano
2013-08-22 21:35 ` Eric Sunshine
2013-08-22 21:43 ` Junio C Hamano
2013-08-22 21:59 ` Eric Sunshine
2013-08-22 22:53 ` Eric Sunshine
2013-08-22 23:12 ` Junio C Hamano
2013-08-22 23:15 ` Eric Sunshine
2013-08-23 4:32 ` Eric Sunshine
2013-08-23 5:36 ` Junio C Hamano
2013-08-23 9:19 ` Eric Sunshine
2013-08-23 17:15 ` Junio C Hamano
2013-08-23 18:51 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqbo4pqvde.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=brian@gernhardtsoftware$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=sunshine@sunshineco$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox