On Tue, Nov 15, 2022 at 12:46 PM Rudy Rigot <rudy.rigot@xxxxxxxxx> 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".)
