I was surprised to not see a mention of `git diff` anywhere in the post.

Out of curiosity, I setup two directories where the second has a new file, a modified file, and a removed file compared to the first:

    $ tree dir1/ dir2/
    dir1/
    ├── empty.txt
    ├── modified.txt
    ├── remove-this.txt
    └── unchanged.txt
    dir2/
    ├── empty.txt
    ├── modified.txt
    ├── new-file.txt
    └── unchanged.txt

Then `git diff --name-status dir1 dir2` outputs the following, showing the changes by file name.

    $ git diff --name-status dir1 dir2
    M       dir1/modified.txt
    A       dir2/new-file.txt
    D       dir1/remove-this.txt

This also doesn't require running `git init` on the two directories either, so it's immediately usable out of the box.

I suppose you could make a similar thing happen based on git, or maybe even a combination of `find` and `diff`.

It’s certainly an interesting debate whether to use a general-purpose approach vs creating a dedicated and fully customisable implementation. In this case, I was interested in the exact numbers and output structure that snapdiff produces. I’m not sure what it would take to make the same output happen by using git, or how well that would work on directory sizes in (or beyond) the 100.000 files / 100 GB region.

If someone would be up for trying that out and sharing their insights, I’d be interested to learn about it.

A single git repo keeps all history as compressed objects under .git and would continue to grow in size, while OP is deleting older snapshots to reclaim disk space. So it doesn't really fit the git use case.

That was my first thought. A content addressable file system* like Git or Mercurial, would be the simplest thing that could work. * Not sure these VCSs could be called a CAS.