@b0rk Why not write a shell function which overrides cd() and does a quick ‘git stash -m “cdtemp” && git checkout’ when the destination appears to be a commit hash? You could even autocomplete commit hashes into your cd commands …
Sure, you could wrap all that up into a read-only FUSE module, but the shell script is how this old sysadmin thinks about things.
@b0rk Be nice if we could treat social media more like improv, where "Yes, and..." is the golden rule.
I have never used it but I think ClearCase works a bit like your description, so it's a sufficiently cromulent idea to have a $$$$ product based on it...
@b0rk seems neat, tbh, and I’d love to see it. (And if someone’s going to do that, a fuse file system where the root directory is the commit id and the entire repository existed underneath it to allow easy shell tool twiddling between different commit states would be neat too)
@loke@b0rk probably they say that because they don’t want to change.
But having a file system with version control is the best solution: not only ensures full integration with the operating system and the applications, but the interface is already known by the users.
@rogersm@b0rk everything old is new again. Versioned filesystems was a thing back in the good old days, but then Unix needed to fit in 40k RAM and everyone decided that that was what everything should emulate.
@b0rk I'm now thinking about writing in Go a FUSE fs that exposes any io/fs.FS.
I recently wrote an io/fs.FS that exposes an SQLite Archive. https://github.com/dolmen-go/sqlar
@b0rk Not exactly the same but there is Git9 which is an interface to a Git repository as a file system. It only works on 9front afaict https://orib.dev/git9.html
@b0rk FWIW, I have had gcd (Git cd) as an alias for git checkout for ages, and I teach new people to think about branches and commits as directories which just happen to be in the same place. It works quite well.
@b0rk bup (https://bup.github.io/) has something kind of like this. It's not Git, but it is a versioned backup system that uses Git's object storage model, where individual backups are kind of akin to commits. There is a bup fuse command that mounts a filesystem with a view of the backup directory, and all the backups are represented as folders. So I wouldn't be surprised if the implementation of bup fuse could be modified slightly to do the same thing for Git.
@b0rk well sure, but the FS isn't used for making commits (because it's read-only) just for displaying them. I suppose if you want to reassure yourself that you haven't accidentally made any changes .
@b0rk the EdenFS portion of Sapling (https://github.com/facebook/sapling/) has the guts of this inside. Even though that project was built primarily for Sapling (an evolution of Mercurial), it can also mount Git repos. We talked about exposing literally the interface your described for some internal infrastructure in the early days. I'm no longer part of that team so I'm not sure if that ever got implemented, but it wouldn't be difficult if someone was motivated!
@b0rk while I'm remembering stuff, there was also a precursor internal project called gvfs (git view filesystem) that also had this interface. Reading the root directory showed no entries (because there were too many commits and ls needs to stat everything by default -> too costly), but you could cd/ls into a commit hash and see the tree at that commit. That was used to serve up commits for some internal build infrastructure.
@konnorrogers the difference is that git worktrees make you materialize the files on disk (they take up disk space) and this thing would use 0 disk space but would have a folder for every single git commit you've ever made
@b0rk That sounds a bit like ClearCase, a proprietary revision control system that worked roughly that way. It was really sluggish and resource intensive.
@not2b@b0rk I have only bad experience with ClearCase, but one of my coworkers insists that somewhere in its massive configuration space is a good, working system - we just live somewhere else at <EMPLOYER>.
File-based changes and the ability to specify which revision/branch you want on a per-file basis is a lot of power, but it can make things complicated.
Add comment