Need help?
<- Back

Comments (34)

  • thewisenerd
    > 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/
  • chungy
    Related: Fossil has a `fusefs` subcommand: https://fossil-scm.org/home/help/fusefsThe 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
  • Someone
    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.
  • pvtmert
    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.
  • IshKebab
    > 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.
  • ulrischa
    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
  • ramses0
    This is my favorite cursed finding: https://github.com/zevweiss/boozeFUSE-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.
  • steveBK123
    NFS.. stop right there
  • LoganDark
    I feel like mounting Jujutsu changes as folders would be more practical since they're stable across rebases?
  • deepspace
    The dot-com era called. They want ClearCase back.
  • everybodyknows
    2023.
  • cyberax
    BTW, if you want a simple NFSv4 client in Go, feel free to use mine: https://github.com/Cyberax/go-nfs-clientMaking it into an NFSv4 server should also be pretty easy.
  • retrocryptid
    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.