Re: [PATCH v5] status: long status advice adapted to recent capabilities

[Eric Sunshine <sunshine@sunshineco.com>]

On Tue, Nov 15, 2022 at 12:46 PM Rudy Rigot <rudy.rigot@gmail.com> wrote:
> Thanks for the feedback, and I'll integrate it into a new patch, most
> likely today.

Thanks. I think this is _almost_ there; much more polished than
earlier iterations. Hopefully, one final reroll will make it complete.

> > To what does "this" refer? Is it this repository? Or something else?
>
> Hah, good point. The accurate answer is "the status of currently
> existing files is being cached, and we'll watch what files changed
> after now so we only run things on those next time". Obviously that
> would be too verbose for the inexperienced user hitting this, really
> this line is here to convey "if you run it again, it's probably going
> to be faster".
>
> Here are some ideas:
> - "but this result is currently being cached."
> - "but git status results are currently being cached." (true but not
> perfectly accurate since index updates don't only happen on git
> status)
> - "but untracked files are currently being cached." (not completely
> accurate, I believe the index is updated for all files; the untracked
> files are only the interesting ones for this specific performance
> consideration)
> - "but the results were cached, and your next runs may be faster."
>
> I could use some guidance on what would make most sense here. I
> strongly feel like the user should know of it since that's been what's
> been confusing the users of our very large repo specifically when
> their git status is temporarily slow; but I don't have any opinions at
> all about the right phrasing. For now, I'm planning to use the latter
> bullet point in my next patch because it's the most explicit, but I'd
> be glad to apply someone else's take on this instead.

Reading the proposals while wearing the hat of someone who has never
had to deal with speeding up untracked-file bookkeeping and who may
not even know that remedies are available (as discussed in the
documentation), I find that the first three bullet points convey no
meaning at all; they leave the reader hanging. The final bullet point,
on the other hand, tells the user something conclusive. I _very_ much
prefer the final proposal.

(In "but the results were cached, and your next runs may be faster.",
I might suggest dropping "your" -- i.e. "... and subsequent runs may
be faster".)