has anyone made a read-only FUSE filesystem for a git repository where every commit is a folder and the folder contains all the files in that commit?
the idea is that you could just run `cd COMMIT_ID` and poke around instead of checking out the commit
and maybe the branches could be symbolic links to the commit folders?
guys this is such a fun idea I cannot believe people are in the replies trying to explain to me why they think it is impractical
the whole point of computers is to do impractical things and see what happens
seems like the answer is yes!
- https://github.com/fanzeyi/giblefs (fuse implementation in rust where every commit is a folder)
- https://orib.dev/git9.html (for plan 9)
would love to hear about any others
ok I got extremely nerd sniped and made my own version of this “filesystem where every git commit is a folder" thing https://github.com/jvns/git-commit-folders
I wrote a FUSE version and an NFS version that I think will be easier for mac users to use. it definitely does not work on windows.
it probably has about 5 million bugs but it seems to kind of work
the main reason I've found this "all your git commits are folders" feature to be useful is for searching past code: I can run `grep someFunction branch_histories/main/*/commit.go` to find the old version of someFunction I deleted. There are other ways to do that in git but this is easier.
or if I want to just quickly look at a file on another branch to copy a line from it, I can run `vim branches/other-branch/go.mod`
curious about other use cases
@b0rk I used it many years ago, but I’m pretty sure this is the feature: https://www.ibm.com/docs/en/rational-clearcase/9.0.2?topic=views-multiversion-file-system
At the time, I thought it was neat, and I was curious enough to try to figure out how it worked. But it always seemed like a strange choice as the main/default way to interact with an RCS.
@b0rk if I want to find a past piece of file contents on a known branch, there are existing ways, like git log -G. I think where your thing would be *really* useful is if I can't even remember which *branch* it is.
"I remember that somewhere among my 50 half-finished dev branches I added a function called do_useful_thing(), but arrgh, which one?"
There is "git grep" for that.
@b0rk @albertcardona you can make it search a specific commit in place of the worktree, so you could do something like
for r in $(git rev-list <params>); do git grep search_term $r; done
but it's cumbersome, and doesn't annotate the results with which commit they came from, unless you add a further "| sed" or some such. But with a git-fuse filesystem you could do this, which is short and simple and does show where it found the term:
grep search_term gitfs/*/*/foo.c
@simontatham @b0rk git log -G is great for searching in the commits diffs, but for addition/deletion specifically -S is awesome. It lists only the commits where the number of occurrences of the string changed.
https://git-scm.com/docs/git-log#Documentation/git-log.txt--Sltstringgt
@b0rk This is really neat! It feels a lot more straightforward than existing equivalents like git-grep or editor plugins. Very cool for these existing tools to suddenly work with git “for free”.
I wonder if you could make saving a file from an editor do something useful. Maybe make a branch with a name based on the process name/pid and commit to that?
@b0rk Perforce’s use of increasing revision numbers for files makes it an easy fit for the ussr’s mental model: “The latest revision is 5, but I want to see revisions 4, 3, 2, and 1.” The way Perforce handles branching also fits: different paths for each branch, so branch-a/file has a different set of revision numbers than branch-b/file.
I’m not sure how best to map a “revision slider” to users’ various mental models of git.
@siracusa what i'm doing in my commit folders project (which is kind of silly but sort of works) is numbering the revisions backwards -- so you have branch_history/main/0, branch_history/main/1, etc. 0 is the latest and the other numbers are relative
the numbers wouldn't be stable, but you can say something like “as of 912da3150d9cfa74523b42fae028bbb320b6804f, 5 versions ago”
@oblomov @siracusa @b0rk With "git gui blame" you can even go backward and forward in time, selecting the line and going back to how it looked before (and how the rest of the file looked like then).
And "git gui blame" shows when the line changed both with and without code copying detection (if they differ, it may be because the code was moved and copied from other file: one column would show when it was moved, one when it was introduced/changed).
@siracusa @b0rk Git itself has a built-in tool that does almost exactly this -- `gitk`: https://git-scm.com/docs/gitk (Seems to be another instance of a cheekily/unclearly-named Git Thing because the UI is written in Tcl/Tk.)
Running `gitk -- path/to/file` shows a UI that lets you quickly jump between all commits that revised that file, showing only the changes to that file.
Is installable via Homebrew on Mac with `brew install git-gui` -- git-gui is another related tool: https://git-scm.com/docs/git-gui
@b0rk Brilliant!
Exposing things as filesystems rocks! It becomes ridiculously useful to be able to do things like grep and write scripts against stuff like service discovery, ldap/ad, or weird metrics exporting (jmx, snmp, etc).
"Everything SHALL be a file” :-)
Julia Evans
John Siracusa
hrbrmstr 🇺🇦 🇬🇱 🇨🇦
Petru Ratiu
Sumurai8
Simon Tatham
Albert Cardona
Étienne Barrié
Ben Hutchings
Adam Johnson 
Adam Roben
folkert van heusden
Aron Ambrosiani
Steven Woolgar
Francis 🏴☠️ Gulotta
Drew Breunig
Oblomov
Jakub Narębski
yertle
Rich Loveland
Marid Vex de Uill
John Vert
Josh Dick 
Edmund
Rhizomatic Arcade
Richard Barrell
jrjsmrtn
Brian McCallister
Daniel Schildt
Peter Binkley
John Mitchell
Johnathan Corgan
Ben Cardoen