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!
