@simulacrum what do you think of PR #69527 ?
if it works I'm all for it I think
the only problem I could imagine with this strategy
presuming it's not a massive slowdown?
is if you add a lot of untracked files
then presumably we'll do some amount of unnecessary work
eh, I think it's probably not too bad
I'm going to approve it
I too expect that this will not matter in practice. Especially since I'm not doing
git status --untracked=all.
Did you consider
files. Because it takes extra work to find untracked files in the filesystem, this mode may take some time in a large working tree. Consider enabling untracked cache and split index if supported (see git update-index --untracked-cache and git update-index --split-index), Otherwise you can use no to have git status return more quickly without showing untracked files.
I guess if it's taking a long time we can presumably tell people to use that
I was unaware of the
--untracked-cache option. And yes, if someone actually complains about this in the wild, then we can put something in (e.g. emit a warning if the set of untracked files we add is huge)
mhm. rustfmt is already pretty slow (mostly because we're running it on every file individually, I think, though unsure), so I think this is not that big a deal