Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

77% Positive

Analyzed from 1158 words in the discussion.

Trending Topics

#nfs#git#server#client#log#https#com#files#need#network

Discussion (36 Comments)Read Original on HackerNews

thewisenerdabout 3 hours ago
> 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/

js2about 3 hours ago
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.

chungyabout 3 hours ago
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

Someone2 days ago
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.

blaz0about 4 hours ago
macOS actually has an excellent SMB client, so the options actually are: WebDAV, NFS (3.0 and 4.0), SMB, FSKit.
oefrhaabout 3 hours ago
By excellent do you mean bearable? macOS’s SMB stack is certainly not excellent.
nine_kabout 2 hours ago
Won't the SMB implementation be sufficient to mount git commits as folders?
adi_kurianabout 3 hours ago
By bearable do you mean it exists? It's fucking shite.
js2about 3 hours ago
AFAIK, SMB doesn't support symbolic links.
pvtmert2 days ago
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.
ramses0about 3 hours ago
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.
ulrischaabout 3 hours ago
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
wtallisabout 3 hours ago
Files and folders can be read-only, a concept that has been around for about as long as the folders abstraction itself.
IshKebab33 minutes ago
> 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.

steveBK123about 3 hours ago
NFS.. stop right there
mmh0000about 2 hours ago
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
chungyabout 2 hours ago
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.

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

Export as read only?

projektfuabout 2 hours ago
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.
mmh0000about 2 hours ago
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.

IshKebab25 minutes ago
Even worse is the .nfs "silly renaming" nonsense. I was under the impression that NFSv4 fixed that but someone told me it doesn't.
nine_kabout 2 hours ago
Does this mean that I can connect to an NFS server saying my UID=0 and get local root?
mmh0000about 2 hours ago
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.

steveBK123about 2 hours ago
So many battle scars from NFS in production for me as well.

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

skydhashabout 2 hours ago
> 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.

mmh0000about 2 hours ago
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.

LoganDarkabout 2 hours ago
I feel like mounting Jujutsu changes as folders would be more practical since they're stable across rebases?
deepspaceabout 2 hours ago
The dot-com era called. They want ClearCase back.
everybodyknowsabout 2 hours ago
2023.
Advertisement
cyberaxabout 3 hours ago
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.

retrocryptidabout 1 hour ago
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.

mrlonglongabout 1 hour ago
Oh nooooo.