41–50 of 61 posts
Your workspaces were also copy-on-write from the base file revisions you were using.
Earlier quoted context omitted.
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.
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.
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.
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.
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
I wrote my comment two days ago. I don’t think the title contained “(2023)” then.
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 (maybe if there’s a way to do Git LFS style stuff in it)
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.
Earlier quoted context omitted.
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.
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.
> 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…
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.