(opinions are my own)

> Its goal is simple (at least, in principle): automatically identify dead code, and send code review requests ('changelists') to delete it.

It sends CLs (pull requests) and shows up as a commit. You get a chance to approve or deny the deletion

yeah but even if you approve it the code is still there in the code history, right?

Yes.

Good.

But relatively hard to find and work with.

I used to do archeaology on Google's monorepo (IE, looking far into the past of mapreduce, search engine, ads, and other products) and it wasn't really that hard. Heck, there was even a sythetic filesystem where you could just cd to a historical commit # and see a view of the repo at that timepoint (google's version control is based on an always-increasing globally shared commit numbers).

I wrote a similar fuse based file system to do the same thing for git.

It was quite pleasant to write, because both the guy who designed git, Linus Torvalds, is also a file system guy.

Did you open source yours? I started something like this here: https://github.com/gravypod/gitfs

I wrote the original version for a previous employer mostly in Python. So that one is closed source.

I was about to recreate a new version in Rust as an open source project. So I started with fixing up libfuse https://github.com/libfuse/libfuse/pulls?q=author%3Amatthias... and the Rust equivalent https://github.com/cloud-hypervisor/fuse-backend-rs/pulls?q=...

Your project is also interesting. I don't plan on ever adding write support. The old Python version was already using git as a library via gitpython, instead of shelling out via the command line. The new version will use Rust's gix.

Performance, even for the old Python version, was pretty decent. That probably came from using git via a library and being careful about fuse caching. I used the 'low level' API that libfuse provided, instead of the 'high level' one. The old version also already supported opening arbitrary commits, tags and branches, they were represented as different folders.

Another feature that's maybe important for performance: because everything was read-only, operations like OpenFile could be implemented as no-ops in such a way that the kernel doesn't even send us a request anymore.

(It was read-only in the sense that any changes would come from the git side. User initiated file system operations could not make any changes to the data.)

I sent you a pull request to improve performance a bit.

Still fairly easy to find IMO. You can search deleted code easily, and blame layers allows finding how code evolved fairly quickly.

I still would like a better way to follow a line back through history. But what we have is already pretty good.

Not really. If you're in the very rare situation where you need to diagnose a bug in long-since dead code, you can just view repository synced to where the version was cut.

No you just go to the folder and select “show deleted”.

Don't even need to do that. Codesearch with a `from:0` qualifier does full regex search on the history iirc

thank you