Thanks a lot for all that feedback. Honestly you're way more familiar than I am with both how the underlying features work, and how to best contribute this change, so I'm comfortable taking your advice pretty much blindly. > Let me suggest an alternative commit message. We want to lead with a > "command" -- as in: "make Git do this" or "teach Git to do this". Then > explain why. Oops, sorry for missing this. Well, your commit message suggestion is flawless, I will reuse this as is. Thanks a lot for spending time polishing it. > I hate to suggest a complete rewrite > [...] > Something like that. Hope this helps. (And again, sorry for the rewrite.) There's absolutely nothing to apologize about. This is great! I will also reuse as is. Here too, thanks a lot for the time spent on this! > small nit: we should have a final LF at the end of the file. Sounds good, will fix. > I'm going to skip over the test cases because I'm running > short on time this afternoon. That's all good, I need to align my submission to all this and resubmit anyway, so you got time! I'm pretty confident about them too, a lot more than in the phrasing of the user-facing content I had. > Also, we should refer to the documentation via `git help` rather > than as a link to the website. Oops, I didn't realize people were getting the same content from either. I will fix. > I'm not sure I like the various mixture of messages here. Maybe > it would be better with a single simple message: That's the one thing I'm a bit concerned about, that I would like to discuss more if that's ok. The current confusion we're seeing with users of our very large repo, is that they run git status the first time and notice it being slow (~30s), and then they see the current advice message advising that they're supposed to do something about it. What they don't know, is that untrackedcache and fsmonitor were already set for their environment, by the script setting their entire environment up. I don't think it is unusual for users to not necessarily know how their environment was configured (either because someone/something else did it for them, or because they forgot what they did for this specific repo, for instance). So with that, I worry about the phrasing "See 'git help status' for information on how to improve this." in that use case, because it implies that there is something they are expected to go improve, while that was already done. Here are some solution ideas: * Changing the wording for all use cases to not convey that they must do anything about it. For instance just "See 'git help status'". (I don't love this because I could imagine users being puzzled about why Git is telling them this, then.) * Informing the user of their current caching situation in ways that they can deduce whether or not they should be doing something about it. That's what I was attempting to do here, but reading your help content, I think I got something wrong: I didn't realize the cache would only need to warm up with untrackedcache + fsmonitor, and not with untrackedcache alone. So with that an improvement could be to only display "but this is currently being cached." when both untrackedcache + fsmonitor are on, and not display anything different when only untrackedcache is on then when it's not. * Not displaying this advice message when fsmonitor is on, since the best possible optimization was already applied. Not loving it, because some could also still want untracked files off on top of it. Also, it doesn't resolve the frustration of noticing git status being slow the first time. For now if you don't mind, I'll change things to the 2nd proposal up there, but this is not because I'm rejecting your guidance and insisting that adding a line here is the right solution to the situation of environments that were already optimized, and I'm not sure what is. But I do worry that telling those users that they should optimize things while they/someone already did will surely be confusing. I'll work on the other fixes, and I am deeply interested in your thoughts about this one. Thanks a lot for working through this with me.