4 ms·

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

(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

kragen 3y ago
yeah but even if you approve it the code is still there in the code history, right?
- bradfitz 3y ago
  Yes.
  - DamonHD 3y ago
    Good. But relatively hard to find and work with.
    - tonfa 3y ago
      Still fairly easy to find IMO. You can search deleted code easily, and blame layers allows finding how code evolved fairly quickly.
      - larsrc 3y ago
        I still would like a better way to follow a line back through history. But what we have is already pretty good.
    - kevinoconnor7 3y ago
      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.
    - pradn 3y ago
      No you just go to the folder and select “show deleted”.
      - dmoy 3y ago
        Don't even need to do that. Codesearch with a `from:0` qualifier does full regex search on the history iirc
    - dekhn 3y ago
      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).
      - eru 3y ago
        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.
        gravypod 3y ago
        Did you open source yours? I started something like this here: https://github.com/gravypod/gitfs https://github.com/gravypod/gitfs
        eru 3y ago
        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%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.)
  - kragen 3y ago
    thank you

kragen 3y ago

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

bradfitz 3y ago
Yes.
- DamonHD 3y ago
  Good. But relatively hard to find and work with.
  - tonfa 3y ago
    Still fairly easy to find IMO. You can search deleted code easily, and blame layers allows finding how code evolved fairly quickly.
    - larsrc 3y ago
      I still would like a better way to follow a line back through history. But what we have is already pretty good.
  - kevinoconnor7 3y ago
    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.
  - pradn 3y ago
    No you just go to the folder and select “show deleted”.
    - dmoy 3y ago
      Don't even need to do that. Codesearch with a `from:0` qualifier does full regex search on the history iirc
  - dekhn 3y ago
    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).
    - eru 3y ago
      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.
      - gravypod 3y ago
        Did you open source yours? I started something like this here: https://github.com/gravypod/gitfs https://github.com/gravypod/gitfs
        eru 3y ago
        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%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.)
- kragen 3y ago
  thank you