> None of these are the most efficient way to do this (you can use git show and git log -S or maybe git grep to accomplish something similar), but personally I always forget the syntax and navigating a filesystem feels easier to me.
i feel like some of the old-school commands will benefit from long args, e.g., '--search'. at the time of writing, the current `git log` documentation[1]'s `-S' has _one_ instance of the word 'search'.
(un)related to the article, author went on to contribute documentation updates to git, which were much needed [2]
The two filesystems I could that were natively supported by Mac OS were WebDav and NFS. I couldn’t tell which would be easier to implement so I just tried both”
Nice idea. But when taking commits as folders one should delete, add and remame files in the folder and that is not possible in a commit because it creates another commit.
So I think this is nit the right mental model
Given the advent of LLMs and agentic coding, I believe this article needs re-visiting as it makes it much more discoverable to compare individual files across commits.
> None of these are the most efficient way to do this (you can use git show and git log -S or maybe git grep to accomplish something similar), but personally I always forget the syntax and navigating a filesystem feels easier to me.
i feel like some of the old-school commands will benefit from long args, e.g., '--search'. at the time of writing, the current `git log` documentation[1]'s `-S' has _one_ instance of the word 'search'.
(un)related to the article, author went on to contribute documentation updates to git, which were much needed [2]
[1]: https://git-scm.com/docs/git-log#Documentation/git-log.txt--... [2]: https://jvns.ca/blog/2026/01/08/a-data-model-for-git/
What, you didn't know to search for pickaxe!? :-)
Meanwhile, --grep searches the log message. Yeah, the git CLI is an ergonomic nightmare and I've been using it since the very beginning.
FWIW, I can't think of a single time I've wanted to use -S instead of -G.
FTA: “problem 1: webdav or NFS?
The two filesystems I could that were natively supported by Mac OS were WebDav and NFS. I couldn’t tell which would be easier to implement so I just tried both”
I might find out that it is incomplete, buggy or a nuisance to use, but FSKit (https://developer.apple.com/documentation/FSKit) would be my first choice.
macOS actually has an excellent SMB client, so the options actually are: WebDAV, NFS (3.0 and 4.0), SMB, FSKit.
AFAIK, SMB doesn't support symbolic links.
By excellent do you mean bearable? macOS’s SMB stack is certainly not excellent.
By bearable do you mean it exists? It's fucking shite.
Related: Fossil has a `fusefs` subcommand: https://fossil-scm.org/home/help/fusefs
The DIRECTORY/checkins/ directory doesn't list out anything by itself, but you can look things up by any of the supported checkin names (hash, tag, branch, date...): https://fossil-scm.org/home/doc/trunk/www/checkin_names.wiki
Nice idea. But when taking commits as folders one should delete, add and remame files in the folder and that is not possible in a commit because it creates another commit. So I think this is nit the right mental model
Files and folders can be read-only, a concept that has been around for about as long as the folders abstraction itself.
BTW, if you want a simple NFSv4 client in Go, feel free to use mine: https://github.com/Cyberax/go-nfs-client
Making it into an NFSv4 server should also be pretty easy.
Given the advent of LLMs and agentic coding, I believe this article needs re-visiting as it makes it much more discoverable to compare individual files across commits.
NFS.. stop right there