Alright, I tried the "status.enumerateUntrackedDelayMS" approach, but I couldn't pull it off and now I am stumped. This is somewhat frustrating, so I'd welcome guidance if anyone has time and is interested. Since this doesn't actually work, I don't think I should create an actual patch for it on the mailing list, so here are two other ways to show what I've got, I hope they're acceptable: - in Gist form: https://gist.github.com/rudyrigot/aa3e8e5ddb4f71fdc7fc0e92d9b7a4b8 - in GitHub compare form: https://github.com/git/git/compare/master...rudyrigot:git:status_enumerateUntrackedDelayMS The issues I'm seeing: - No matter how I set the config from the test, it doesn't seem to have any effect. I'm thinking I might be doing something wrong in how I set the value, which I've done in git_status_config in builtin/commit.c, which very well may be the wrong place. - Therefore, I've been testing things by changing the default value in wt_status_prepare in wt-status.c. Setting it at 0 and making the operator <= instead of < makes the advice display, which tells me that the logic is sound. Setting at its intended value of 2000 doesn't display the advice message, as expected. But setting it at -1 also doesn't display it. I'm a bit puzzled about why that would be, and I'm wondering: maybe the int is unsigned? It doesn't look like it based on how the structure field is declared in wt-status.h, but I know my own limits in C so I could be wrong. Now, I'm also well aware that Junio raised that advice leaving the door wide open to not actually solve this as part of this patch; and I did express in my previous reply that I am not intuitively convinced there is much value to it for users, although I could be wrong of course. So with that, if it's better to let it go, that is fine by me too. With that in mind, I implemented the alternative that Junio was proposing instead (assigning the value of `s->untracked_in_ms`), and it seems to work all good. It just passed CI, so I'm about to submit that as a patch, with every other piece of feedback also addressed. Unrelated note: I noticed that the first 2 bits of feedback applied to docs that were part of past patches, but were removed in the last patch. The rest of the doc feedback was current, so I was able to implement them, but obviously I couldn't implement the first 2 ones, since the issues they're about are gone.
