Re: [PATCH v5] status: long status advice adapted to recent capabilities
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Nov 15, 2022, 18:06 UTC
- Message-ID
- <CAPig+cT2+nitwD64FzG=6FvO7eUn3q-cq_CmmYeOXxOMyzvUnw@mail.gmail.com>
- In-Reply-To
- <CANaDLW+Ec0kY4AW5dGvnCaHgcvFOZQZO5EAi595KbVKj7KDg3g@mail.gmail.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.
Show 27 quoted lines
> > 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".)