Mounting git commits as folders with NFS (2023) | Hacker News Reader

Mounting git commits as folders with NFS (2023)

jvns.ca

117 pointspvtmert58 comments

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

Funny, I use -S routinely and -G rarely: I’m almost never interested in cases where a symbol was moved around, it’s just noise, so always reach for -S first.

-S does not mean “search” tho, it means specifically searching the change history for the symbol being added or removed (but not moved, the number of occurrences has to vary). -G includes the symbol being moved (it will flag commits which both remove and add an occurrence).

“git grep” is the correct tool for Julia’s grep, however as usual it has the worst defaults: the work tree (so it’s just a slightly better “grep”), you need to give it a list of revisions to search to get a history search (so usually you pipe-xargs a rev-list into it).

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

Someday I’ll use fossil.

Someday (maybe if there’s a way to do Git LFS style stuff in it)

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

The blog post is from 2023, one year later she would have gotten FSKit with Sequoia.

https://developer.apple.com/documentation/fskit

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.

We used Clearcase around year 2000 on HP-UX. I found it nice and powerful, but 90% of the developers did not understand it. Well, probably a similar statement holds for git.

I certainly didn’t understand it. We were using it up to 2019. A coworker set up a spec that would automatically mirror to the main codebase, unknown to me that was possible. I made a branch there, did some stuff, and then reverted. Little did I know I was essentially working on production. Broke a bunch of stuff and had to remember what I changed because there was no history. Point is it was too powerful for people that did and didn’t know how to use it.

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"
    }

...I think that WebDAV is "the way" compared to FUSE, but I'm always intrigued by the idea of virtual filesystems as an implementation face.

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

NFS.. stop right there

You're being downvoted, but, seriously... NFS is a joke for anything outside of an enterprise setup with a bunch of ancillary support services in place.

The fact that NFSv4 has no concept of true "Authentication" and just blindly accepts whatever the client sends is the craziest network application design ever:

  Client: Hi, NFS server, I'm Bob! UID=1000
  Server: Hi Bob! Here's access to all of Bob's files! I trust you and don't need a password or anything!
  Client: Thanks!!!

Some of you may nitpick and say, "well ackkkuallyy, NFS supports authentication through GSSAPI/krb."

And to you, I say, that's crazy! Setting up Kerberos just to authenticate users for access to my Linux ISOs is a crazy large requirement! Sure, it might make sense for an enterprise that already uses Kerberos + LDAP + NFS + certificate management, but for everyone else, that's a lot of infrastructure to set up and maintain for what should be BASIC functionality.

EDIT

ALSO!!! Why the fork does NFS run as a kernel module (nfsd)!? Shouldn't that be an external daemon!? Who the heck thought any of this was a good idea!?

  <sarcasm mode> 
    Dev1: Here's a great idea! Let's run an insecure network server in Kernel space! 
    Dev2: OMG! You're so smart! Let's also exclude any encryption!!!
 </>

//end rant of an old, bitter Linux sysadmin

Does this mean that I can connect to an NFS server saying my UID=0 and get local root?

Usually, no. NFS defaults to "root_squash," which silently changes UID=0 to the UID of the `nfsnobody` user.

However, in the /etc/exports file, you can (but shouldn't) add the share option "no_root_squash" which disables that.

So, root access is slightly protected. But all other users are wide open.

At work once someone dockerized a service that needed read access to NFS. The default for a docker image is to run as root, which would mean it was effectively "nobody" when reading over NFS.

For the typical case of world-readable files this was fine. Occasionally someone would feed it a file that was not group-readable but not world-readable and it would error (when it would have worked before).

I suggested printing the error message: "nobody can't read this file" but we solved it in a different way.

Funny part is, that NFSv4 supports SIDs for user authentication, but the Linux implementation leaves it out (among all the other ACL features) simply on the basis that Linux doesn't support them at all.

The FreeBSD, Solaris, Mac OS X, and Windows (yes, even Windows) implementations of NFSv4 are fully featured with this stuff.

I really wanted NFSv4 ACLs but Linux doesn't like it while FreeBSD doesn't make use of my hardware (intel p/e cores) in the most efficient way.

So many battle scars from NFS in production for me as well.

Wish the downvoters all the best in their future NFS endeavors.

> The fact that NFSv4 has no concept of true "Authentication" and just blindly accepts whatever the client sends is the craziest network application design ever

Doesn’t the secure option require ports only a root user can bind too? And you can always create secure tunnels if the physical network is insecure.

Sure, if you (the admin) have full control over the NFS server, the network, and the client devices, NFS can be secure with the help of Kerberos. But this isn't a simple thing. A Kerberos server needs to be set up, Kerberos clients need to be configured on the NFS server and client, tickets need to be issued, firewall ports need to be opened, and user accounts need to be centrally managed. That's all fine for an Enterprise.

Now, how about this common scenario: I want to run a file-sharing server on my network. I want a random "friend" to come over and grab a copy of a file, but I don't want them to see any other files on the NFS server.

So, the "friend" has root access on their device. They can just log in and lie to the NFS server, claim they're my UID, and see all my files that I didn't want them to access. Configuring KRB in that scenario is totally impractical.

> Now, how about this common scenario: I want to run a file-sharing server on my network. I want a random "friend" to come over and grab a copy of a file, but I don't want them to see any other files on the NFS server.

How is that a common scenario? Why not give them your drive and the encryption key while you’re at it? It would be way faster.

The correct scenario would be to just copy the file and serve it with ftp or http on another interface.

Ah, so you agree NFS is not fit for purpose (network file sharing), and I should use something else to share files over the network.

EDIT (the above is a bit more snark than I intended, let me add a little more):

NFS's direct (still widely used) competitor, SMB, natively supports:

  - Authentication
  - Transfer encryption
  - Authentication encryption
  - Has open implementations across platforms
  - Supports individual account management, and large enterprisey account management (LDAP/AD/etc)

With SMB, I can share out a directory on the network that allows visitors access, optionally authenticated with a simple username and password.

I can share out specific directories with easy control over who can access what. You know, basic network file sharing capabilities.

[[ And, don't take this as a love for SMB, it too has many issues and legacy junk ]]

> Ah, so you agree NFS is not fit for purpose (network file sharing), and I should use something else to share files over the network

NFS stands for Network File System, not Network File Sharing. If you gave a disk to someone, the permission bits wouldn’t stand for anything too.

Will this matter if it's running on localhost and only accessible to the users there? She's just using it as a stand-in for FUSE.

To be clear: I am not criticizing the use case in the article. It's a silly, fun, and creative hacking together of technology.

I am criticizing NFS as a whole, and specifically its Linux implementation.

Even worse is the .nfs "silly renaming" nonsense. I was under the impression that NFSv4 fixed that but someone told me it doesn't.

> Setting up Kerberos just to authenticate users for access to my Linux ISOs is a crazy large requirement!

Export as read only?

To be fair setting up a KDC and then distributing krb5.conf and idmap.conf files is not such a hard task.

Then it's not unencrypted anymore because sec=krb5p handles signing and encryption. I have better throughput using sec=krb5p than with samba signing and encryption. I don't know if it's because Samba uses GNUTLS but the transfer speeds are always awful.

My beefs with NFS is MacOS being extremely quirk with settings. That and the extremely misleading error messages.

>Dev1: Here's a great idea! Let's run an insecure network server in Kernel space!

>Dev2: OMG! You're so smart! Let's also exclude any encryption!!!

If it wasn't such a cool idea they wouldn't be doing it again, this time with direct access to memory: https://docs.kernel.org/filesystems/smb/ksmbd.html

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.

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.

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.

Which is why I'm so angry they're killing AFP. It works so much better and is super easy to set up a server for on a Linux

Won't the SMB implementation be sufficient to mount git commits as folders?

No, because SMB doesn't support execute permissions. So either all your files are executable or none of them are.

I would say that in a source code tree that represents old commits I'd like none of the files to be executable. (It would miss some commits that only change the executable bit though.)

AFAIK, SMB doesn't support symbolic links.

Git should not have supported them either.

FSKit was released with Sequoia in March 2025. This blog post was written in December 2023—so at the time it was written, FSKit was not yet an option

HN messes up time stamps when submissions get reposted.

I wrote my comment two days ago. I don’t think the title contained “(2023)” then.

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.

Oh nooooo.

ClearCase was the main system at Altitude Software in Portugal, and at Nokia, eventually replaced by Subversion.

Yes, it was, is, quite complex and requires a dedicated team, however there are plenty of features that are still to be made available as easyly.

I loved my view configurations, there were some tricks we could do for mix and match what code to see, and the build caches to this day is still not as integrated as sharing object and library files was back then.

GE moved off Clearcase in 2019 because even IBM didn’t want to use or support it anymore. Wasn’t set up as bad as you had but wouldn’t describe it as pleasant. Lot of alias cheatsheets. Now we’re on perforce transitioning to git.

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.

and with fuse and webdav you have the power and a possibility to implement your own handler for deleting and renaming, that could do all the tricky git related parts.

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

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

I loved the views, you could actually have snapshots git style, and best of all binary caches for distributed compilation of C and C++, something that is still not widely deployed.

By the way, it is still around.

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

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

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.

2023.

Reply on news.ycombinator.com