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.