Re: [PATCH] fsmonitor: long status advice adapted to the fsmonitor use case

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

Oooh, I definitely like where your mind is with this. I think it makes a
lot of sense, there used to be one way to act upon a slow status, now there
are a few, so I can see how any in-depth explanation here would add to the
confusion for a user in a terminal who is just trying to get things done.
And I see how the current messaging already kinda infringes on that.

Alright, I can write the first draft of the documentation changes you were
mentioning. Heads up though: I'm going to need your tight review of it,
because I'm not as completely comfortable with what each option does as I
wish I was, so I worry I may write something accidentally inaccurate. I'll
take the time to read up on it though, and then I'll try my hand at it and
update it here, and let's take it from there if that sounds good.

With that, I'm thinking the "slow status" advice could be turned into
something as simple as:

> Your git status run was slow, here are some ways to optimize it.
> https://git-scm.com/docs/git-status#_performance_optimizations

(To be clear, I'm very un-opinionated about phrasing.)

There's one thing I'm still worried about though, which is what you
mentioned earlier, and which brought me here: the fact that git-status
feels like a read-only command, but secretly isn't. I'm thinking the
confusing use case is when the repository was in fact set in a way that
things are cached, and yet git-status is still slow because it was
generating that cache, and the user doesn't have a way to know that.

Adding to the murkiness, it might not have been the reason, so I understand
we can't say things in such a confident manner as "it will be faster now",
because of course it depends.

So I'm thinking, after the message above when git-status was slow, in the
specific case where the untracked cache is on (whether FSMonitor is on or
not, since that sounds more like under-the-hood detail), we could display
something like the additional line here:

> Your git status run was slow, here are some ways to optimize it.
> https://git-scm.com/docs/git-status#_performance_optimizations
>
> Your git status run was cached.

If the untracked cache is on, I'm assuming that would be always accurate
information, is that correct?

If you're concerned that users may not understand what it means for them,
we could also make it more obvious without over-committing about it:

> Your git status run was slow, here are some ways to optimize it.
> https://git-scm.com/docs/git-status#_performance_optimizations
>
> Your git status run was cached, it may be faster on your next runs.

What do you think?

To summarize, next steps for me:
- Make the first draft for the doc updates.
- Change the advice messaging based on our discussion above and what you
think of it.
- I still need to look into your test-related advice from last time, I
haven't yet. I really would like to give tests to all this.

Thanks a lot for all this, it helps tremendously!