> But FUSE is pretty annoying to use on Mac – you need to install a kernel extension, and Mac OS seems to be making it harder and harder to install kernel extensions

I'm not a Mac user at all, so there may be reasons what I'm about to suggest is silly beyond the ones I will mention myself, but…

Another way around this is to run the FUSE filesystem in a small VM running a different OS that is more FUSE friendly, then export that filesystem to MacOS using a network filesystem that it natively understands. This may also be NFS so you aren't avoiding NFS if so, but you at least separate the NFS issues from the issues interfacing git (assuming interfacing git with FUSE doesn't have just as many gotchas as using NFS directly).

There are a couple of obvious potential performance issues here. Firstly adding the extra network filesystem layer will likely add a noticeable amount of latency for all operations. You likely have this twice too: if you are reading a repo from the host machine rather than checking out its own copy (which would likely be a significant inconvenience) then the VM will need to access that somehow. Secondly any caching in RAM that the fs->git layer does will mean allocating enough RAM to the VM for that which will be dedicated so not available to other processes on your bare metal. If the amount of memory required is small anyway then this is not a problem, or if letting it swap out to disk (or using a disk based cache in the first place) is significantly less inefficient than constantly rereading+reprocessing the structure that the cache is intended to speed references to, then that is an option too.

> 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/

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

>I don’t know if this is actually a problem or how big of an advantage it would be to use NFSv4.

Of the top of my head only one port is needed for V4.

Thats awful... I love it and will probably start using it immediately :P

A couple other people mentioned ClearCase which has something similar if you use their NFS based thing, you could see file or directory history and info by accessing something like `foo.c@@/versions/5` (which isn't ordinarily visible when listing its directory). Pretty nifty.

Your workspaces were also copy-on-write from the base file revisions you were using.

This is my favorite cursed finding: https://github.com/zevweiss/booze

FUSE-bindings for "filesystems in bash", eg:

https://github.com/zevweiss/booze/blob/master/cowsayfs.sh#L5...

    cs_read()
    {
      if ! [[ "$1" =~ ^/($cowpat)/[^/]+$ ]]; then
        booze_err=-$EINVAL
        return 1
      elif [ "$3" != 0 ]; then
        return 0
      fi

      local msg="${1#/*/}"
      local cow="${1#/}"
      cow="${cow%%/*}"
      cowsay -f "$cow" "$msg"
    }

NFS.. stop right there

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.

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.

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

The dot-com era called. They want ClearCase back.

> I fixed this by defining an inode(string) function which hashed a string to get the inode number, and using the tree ID / blob ID as the string to hash.

The tree/blob ID is already a hash though. You don't need to hash it again. Just use the first 8 bytes of the tree ID as the inode.

I feel like mounting Jujutsu changes as folders would be more practical since they're stable across rebases?

2023.

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.

Oh man. I was just reminded of ClearCase and Perforce and sort of threw up a little in the back of my mouth. You young whipper-snappers who didn't have to use ClearCase and have only used hg or git don't know how bad it could be. When ClearCase was properly configured, it was fine. But having used it at IBM, DSCCC and Bell Canada, only IBM managed it properly. At DSCCC, we had 40 Sun workstations on a single thin-net segment, each of them trying to mount an NFS share from ClearCase. You had to get there at 6AM to be one of the first five people to log in because if you didn't it was unlikely you COULD even log in. I kept a copy of the part of the code I was working with on a tape and would go into the lab and restore it from tape, do some work, then back it up to tape at the end of the day (the lab machines were reformatted at midnight every day.)

But... yes... this is just using NFS locally to see what's already in GIT, which is perfectly find and as Julia says, allows you to appreciate the structure of the git repo. Ignore this old man yelling at clouds.