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

[Rudy Rigot <rudy.rigot@gmail.com>]

Thanks for the feedback, and I'll integrate it into a new patch, most
likely today.

> Does this need to be "inline"?

Oops. Just as I said I don't think I left any feedback unaddressed.
You did mention it last time, and it fell through the cracks. I'll fix
it this time, sorry about that.

> Was there a specific reason you switched around the condition

Totally a whim. After several iterations, the code had changed enough
that the original ordering was lost. I'll switch it back.

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