All of lore.kernel.org
 help / color / mirror / Atom feed
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.

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