> One thing that I find glaringly omitted, which since you're working on > this you might consider adding: Suggest to just try running the exact > same command again, maybe it was just the FS cache. I have to admit that would be by far my personal preference. We've been having a number of very great points made by several people on this thread, but a number of them contradicting each other across people, and yet clearly nobody's wrong, everybody makes very real points. I'm trying to turn this into actionable changes I should make, but I think I need guidance on that. This is my first ever contribution to the project, so I'm lacking the organizational awareness of the project to be able to drive this to a consensus on what we should do. Here's a proposal that tries to make opinionated moves towards what I understand to be the priorities that were expressed: 1- We keep the new paragraph doc, because I'd say why not, it's well-written (thanks Jeff!) and useful. When people are looking for ways to make git status faster, it's good that there's a reference about it, and I'd expect it to be a common need across all kinds of user situations. 2- When untracked cache is not on, if I understand Ævar's suggestion, it would say something like: > It took %.2f seconds to enumerate untracked files. > Try to enable untracked cache to see if it helps make it faster > for you: > git config core.untrackedCache true It would satisfy that the message gives concise advice with actionable next steps, without making assumptions about whether it will or won't work. (Untracked cache alone did not make much of a difference in our very large repo's case.) And it doesn't point to the help anymore, in order not to saturate the user with too much detail. 3- When untrackedcache is on but fsmonitor is off, and git status is still slow (that's the situation we had on our very large repo), it could say something like: > It took %.2f seconds to enumerate untracked files. > Try to enable FSMonitor to see if it helps make it faster for you: > git config core.fsmonitor true Same as before, concise, no assumptions. This setup is more advanced, but we are in a case where untracked cache is not helping, so I'm thining that should be very few repos. If the user feels a need to better understand what's up, the feature is mentioned by name, so they can look it up and dig in if they wish to. 4- When fsmonitor is on: > It took %.2f seconds to enumerate untracked files. > Your runs are being cached, try running git status again to see if > it's faster. Same as before, concise, no assumptions, and matches Ævar's suggestion above that was also my preference, as it would apply perfectly to our very large repo's use case and the grievances we've received. Please let me know what your thoughts are about it all. A downside with all that is the option to disable untracked files is not mentioned at all, but if we keep the doc as it is, and it gets painful enough that they search for other ways, I'm hopefuly the user would find it there. I want to say it again: I'm not very opinionated about any of this, just trying to collate feedback into an actionable plan. If I understood feedback wrong, or my plan is not the best based on the feedback, that is very fine, but I will need guidance to know what makes more sense. > the untracked cache is > pretty much an unambiguous win (we should probably turn it on on > default, but we'd need to check on-the-fly if the FS supports it > properly). I could take on the work to make untracked cache on by default after this, as another patch, if it sounds relevant to try. I feel I lack the technical understanding of what we need to check that you're mentioning here, so I'll have questions, but I'd be on board with trying.
