On Thu, Nov 03 2022, Rudy Rigot wrote: >> looking up an unknown configuration variable with 'man >> git-config' is easy enough. > > I'm not strongly opinionated, but I believe the initial idea behind > redirecting them to the doc was because Git now comes with more > configuration abilities to improve performance of git status, that may > be more or less relevant depending on use cases, so there > isn't really a single git-config key for them to look up any more. Their > ideal solution could be core.untrackedCache=true, core.fsmonitor=true, > advice.statusUoption=false, status.showUntrackedFiles=false, or even > some combinations of those can be relevant. > > From there, the goal I believe we were going for with this new doc > section is to let users know what configs exist for their git status > slowness pains and why, so they can then go look those configs up for > more details, which I agree would indeed be easy from there. > > Again, I'm not strongly opinionated, and I hope I accurately represented > the inital thinking on this idea. > > One slightly stronger opinion I have, is that if the advice message > was just > >> It took %.2f seconds to enumerate untracked files. > > and nothing else, I can definitely see a strong UX downside of not > giving a hint of next steps for users. Basically, "you have a problem, > and we're not helping you resolve it". Were you thinking more of > something like this? > >> It took %.2f seconds to enumerate untracked files. >> Please look up the core.untrackedCache, core.fsmonitor >> advice.statusUoption, and status.showUntrackedFiles configs >> for potential solutions. > > I'd say that's probably somewhat cryptic and a bit verbose (which is > what we were trying to avoid by telling them to go see the doc), but > we wouldn't be leaving the user stranded, so I can see how that would > work out ok. > > I'm very interested in what you think. On the topic in general: I think it's probably a good thing to show the advice, but I just want to point out that it's not without cost. Right now we're showing users a pretty basic command they can try, but now we're showing them other stuff that needs more complex setup. For some they're probably way better off, e.g. 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). But for e.g. fsmonitor the user may spend a lot of time fiddling with it, only to find it doesn't help their use-case much, if it all. Should we still point out these possibilities? Probably, but just say'n. 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.e. we're suggesting all this advanced stuff, but by far the biggest difference is made on e.g. a modern *nix box (particularly Linux) by just having all the repo's assets in the FS cache.
