5 ms·
Yes.
by bradfitz 3y ago
Yes.
- DamonHD 3y agoGood. But relatively hard to find and work with.
- tonfa 3y agoStill fairly easy to find IMO. You can search deleted code easily, and blame layers allows finding how code evolved fairly quickly.
- larsrc 3y agoI still would like a better way to follow a line back through history. But what we have is already pretty good.
- kevinoconnor7 3y agoNot 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.
- pradn 3y agoNo you just go to the folder and select “show deleted”.
- dmoy 3y agoDon't even need to do that. Codesearch with a `from:0` qualifier does full regex search on the history iirc
- dekhn 3y agoI 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).
- eru 3y agoI 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.
- gravypod 3y agoDid you open source yours? I started something like this here: https://github.com/gravypod/gitfs https://github.com/gravypod/gitfs
- eru 3y agoI 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%3Amatthiasgoergens+ https://github.com/libfuse/libfuse/pulls?q=author%3Amatthias... and the Rust equivalent https://github.com/cloud-hypervisor/fuse-backend-rs/pulls?q=author%3Amatthiasgoergens+ 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.)
- eru 3y agoI sent you a pull request to improve performance a bit.
- kragen 3y agothank you