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.
I wrote my comment two days ago. I don’t think the title contained “(2023)” then.
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 (maybe if there’s a way to do Git LFS style stuff in it)
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/
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.
“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).
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!!!
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!!!
</>
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.
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.
The FreeBSD, Solaris, Mac OS X, and Windows (yes, even Windows) implementations of NFSv4 are fully featured with this stuff.
Wish the downvoters all the best in their future NFS endeavors.
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.
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.
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.
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)
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 ]]
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.
I am criticizing NFS as a whole, and specifically its Linux implementation.
Export as read only?
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
Making it into an NFSv4 server should also be pretty easy.
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"
}
By the way, it is still around.
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.
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.
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.
Your workspaces were also copy-on-write from the base file revisions you were using.
Of the top of my head only one port is needed for V4.
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.