Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mounting git commits as folders with NFS (2023)

jvns.ca

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Mounting git commits as folders with NFS (2023)

#51

Post by masklinn »

thewisenerd wrote: post #8

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

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

Re: Mounting git commits as folders with NFS (2023)

#54

Post by irusensei »

mmh0000 wrote: post #17
steveBK123 wrote: post #9

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…

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

Re: Mounting git commits as folders with NFS (2023)

#55

Post by irusensei »

chungy wrote: post #22
mmh0000 wrote: post #17

Earlier quoted context omitted.

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…

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.

Re: Mounting git commits as folders with NFS (2023)

#56

Post by pjmlp »

deepspace wrote: post #23

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.

Re: Mounting git commits as folders with NFS (2023)

#57

Post by dspillett »

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

Re: Mounting git commits as folders with NFS (2023)

#58

Post by pjmlp »

retrocryptid wrote: post #31

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…

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.

Re: Mounting git commits as folders with NFS (2023)

#59

Post by pjmlp »

dspillett wrote: post #57

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

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

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

Re: Mounting git commits as folders with NFS (2023)

#60

Post by olsondv »

usr1106 wrote: post #48
tn1 wrote: post #41

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.
Post reply on HN