All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Klerks <tao@klerks.biz>
To: Jeff Hostetler <git@jeffhostetler.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git <git@vger.kernel.org>,
	Jeff Hostetler <jeffhost@microsoft.com>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: Windows: core.useBuiltinFSMonitor without core.untrackedcache - performance hazard?
Date: Mon, 21 Jun 2021 22:52:02 +0200	[thread overview]
Message-ID: <CAPMMpogjr43111HfPzk23c98JBaiEF2YA_OTkQVG1a63zyeiOw@mail.gmail.com> (raw)
In-Reply-To: <81153d02-8e7a-be59-e709-e90cd5906f3a@jeffhostetler.com>

Hi Jeff, thanks for the update!

On Mon, Jun 21, 2021 at 8:41 PM Jeff Hostetler <git@jeffhostetler.com> wrote:
> We're currently looking at a problem that we believe is in the
> untracked-cache code.  This is causing some of our Scalar tests
> to fail on Windows when the untracked-cache is turned on.

For what it's worth, I just discovered an untracked cache bug this
evening, although I doubt it's related to the one you mention - it's
not very exciting:

If you disable untracked cache (and write an index file), and then
enable untracked cache and run status with "-uall" (writing a new
index file), the untracked cache data written in the new index file is
empty/invalid, and subsequent "git status" calls perform just the same
as if untracked cache were disabled:
----
# write an index without untracked cache
git -c core.untrackedcache=false status

# write another index with invalid/empty/bad untracked cache because
"-uall" skipped its population/maintenance
git -c core.untrackedcache=true status -uall # expected to be slow

# run regular "git status" (with untracked cache) any number of times,
but don't get the benefit (and you don't write a new index because
nothing appears to have changed)
git -c core.untrackedcache=true status # unexpectedly slow
git -c core.untrackedcache=true status # unexpectedly slow
git -c core.untrackedcache=true status # unexpectedly slow
---
# TO FIX:
# write a new index file without untracked cache
git -c core.untrackedcache=false status

# run regular "git status" (with untracked cache), does work and
writes a new index file
git -c core.untrackedcache=true status # slow as expected

# run regular "git status" (with untracked cache) any number of times,
is fast as expected
git -c core.untrackedcache=true status # fast as expected
git -c core.untrackedcache=true status # fast as expected
git -c core.untrackedcache=true status # fast as expected
----

I suspect this issue has bit me in the past when attempting to
understand untracked cache behavior; it can be *very* confusing, if
you're using tooling like "git extensions" that can, in the above
flow, "poison" your untracked cache if it just happens to run a "git
status -uall" in the background as you are testing.

(I discovered this issue while trying to understand the weird &
wonderful relationship between the repo-level untracked cache
reference, the dir-level untracked cache reference, and the mechanisms
that initialize a new one at dir.c#new_untracked_cache() and write the
repo-level one (even if the dir-level reference was voided due to flag
mismatch) at dir.c#write_untracked_extension())

Should I be reporting this in some more "official" form somewhere? Is
there a bug DB?

Thanks,
Tao

  reply	other threads:[~2021-06-21 20:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10 10:24 Windows: core.useBuiltinFSMonitor without core.untrackedcache - performance hazard? Tao Klerks
2021-06-11  9:49 ` Johannes Schindelin
2021-06-21 12:50   ` Tao Klerks
2021-06-21 18:41     ` Jeff Hostetler
2021-06-21 20:52       ` Tao Klerks [this message]
2021-06-24 18:51         ` Tao Klerks
2021-06-24  5:25       ` Tao Klerks
2021-06-24 13:10         ` Jeff Hostetler

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=CAPMMpogjr43111HfPzk23c98JBaiEF2YA_OTkQVG1a63zyeiOw@mail.gmail.com \
    --to=tao@klerks.biz \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=dstolee@microsoft.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=jeffhost@microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.