From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Tao Klerks <tao@klerks.biz>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Feb 2022, #07; Fri, 25)
Date: Mon, 28 Feb 2022 14:42:18 +0100 [thread overview]
Message-ID: <220228.8635k35chr.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <CAPMMpojgTcp7qGmpK0vm8_WTOaSJ6r=NBa3sEO0EC7XRBF_dXg@mail.gmail.com>
On Mon, Feb 28 2022, Tao Klerks wrote:
> My apologies if this is not the right forum for commenting on these summaries;
>
> for tk/untracked-cache-with-uall, I believe the current description is
> misleading:
>
>> The untracked cache system does not work well when the setting of
>> status.showuntrackedfiles is 'normal' and not 'all', which has been
>> updated.
>
> It's almost exactly backwards, in that the case where untracked cache
> gets bypassed is when you specify "all". The "what we do" section is
> also slightly overambitious as the fix is limited to improving
> performance / supporting the cache when runtime flags are consistent
> with configuration, which will improve a couple cases, worsen one
> specific and (I believe) rare case, and not change most.
>
> If I could reword, it would look something like this:
>
> The untracked cache system is bypassed when a command runs
> with the "showuntrackedfiles" flag set to "all" via config or arguments,
> because untracked cache content of "normal" is incompatible with
> "all" and vice versa.
> Instead use it whenever runtime flags are consistent with
> configuration, so that frequent users of "-uall" can get consistent
> performance by setting status.showuntrackedfiles config to "all".
>
> This is quite verbose, but I can't figure out how to condense the concept
> further.
Perhaps something like this:
The performance of the "untracked cache" feature has been improved in
common cases where "--untracked-files=<mode>" and
"status.showUntrackedFiles" were combined. This change benefits Windows
users using it in conjuction with the "fsmonitor feature in particular.
Perhaps adding:
There's an obscure case where the performance is now worse, but it's
thought not to matter.
I guess al of that is somewhat equivalent to an even less verbose:
The untracked cache is [mostly] fasterer, don't worry your pretty little head
about the details.
:)
I.e. it's trying to avoid going into all the details.
next prev parent reply other threads:[~2022-02-28 13:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-26 2:44 What's cooking in git.git (Feb 2022, #07; Fri, 25) Junio C Hamano
2022-02-26 8:54 ` en/merge-tree (Was: Re: What's cooking in git.git (Feb 2022, #07; Fri, 25)) Elijah Newren
2022-02-26 9:11 ` en/present-despite-skipped " Elijah Newren
2022-03-07 16:15 ` Johannes Schindelin
2022-02-28 12:38 ` What's cooking in git.git (Feb 2022, #07; Fri, 25) Tao Klerks
2022-02-28 13:42 ` Ævar Arnfjörð Bjarmason [this message]
2022-03-01 11:56 ` Tao Klerks
2022-03-01 18:06 ` Junio C Hamano
2022-03-01 19:25 ` Tao Klerks
2022-02-28 13:56 ` ds/commit-graph-gen-v2-fixes (was Re: What's cooking in git.git (Feb 2022, #07; Fri, 25)) Derrick Stolee
2022-02-28 14:10 ` ab/test-lib-tweaks (was: " Ævar Arnfjörð Bjarmason
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=220228.8635k35chr.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tao@klerks.biz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).