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.
