Very interesting, thanks! Although I'm not on Windows myself :)

(Which is indeed a relevant amount of faster compared to the shell version, contrary to what I claimed above! I think I might have measured incorrectly. But this all seems to vary quite a bit. But eithe way, the config didn't seem to help.)

Let's try this one.

git config --global core.untrackedCache true

With this setting, I've now been running the rust version of my git-dirty-checker under hyperfine to measure run time. It doesn't seem to make much of a difference. Around 210 ms for each run, with or without the option.

There is also the "untracked cache":

git-scm.com/docs/git-upd...

I'm not exactly sure how these options relate to, or play along with, each other...

Seems like it'd be nice to have some kind of cache that gets invalidated on file system activity. Git actually has something exactly like this built-in, the fs-monitor:

git-scm.com/docs/git-fsm...

Is that of any help to our use case?

it('sums correctly', () => {
expect(sum(3, 0)).toEqual(3);
});

Seems to work fine!

And it's not about shelling out to git. It simply takes some time to do a "git status" – it needs to traverse through the directory tree to find any files not in the git index.

So this approach is still way too slow for the kind of use case I discussed above. And it's not a matter of programming language. For example, I have a Rust version under here:

github.com/skagedal/ska...

It does the same job in about 0.45 seconds.

Adding parallelism (here using GNU parallel) helps a lot:

printf '%s\n' ~/code/*/ | parallel 'git -C {} status --porcelain 2>/dev/null | grep -q . && realpath {}'

On the same set of repos, this takes 0.5 seconds.

To take one step back, here's a brute force solution as a bash one-liner:

for dir in ~/code/*/; do git -C "$dir" status --porcelain 2>/dev/null | grep -q . && realpath "$dir"; done

This takes about 10 seconds on my example set.

Imagine the end goal use case something like this:

my shell prompt should include the number of dirty repositories under my ~/code directory.

Clearly, assuming that I have let's say hundreds of repos, this means caching. But how?