Introducing Gix of Theseus

[amedeedaboville]

👋 Hi, big fan of gitoxide here!

Seeing the work on gix-blame got me interested to see if Git Of Theseus could be reimplemented in gix. I had the hope that some of gix’s blame machinery could be reused but in the end implemented an incremental version of blame myself (the blame cache in #1852 might be useful for this).

Here's the result: https://amedee.me/introducing-gix-of-theseus/ . I called it gix-of-theseus since gitoxide was so useful in implementing this performantly. I used this functionality:

• revwalk to list the commits on the main branch
• tree::diff_with_rewrites to diff the trees of all the weekly commits (with rename tracking)
• diff::blob_diff to compare different revisions of the same file (during the actual blame)
• (and the fact that everything meshed seamlessly with rayon to give basically optimal parallelism)

My only question/comment is that the number of crates installed by the main gix crate seems high to new users just downloading my tool with cargo-install, even with default-features turned off. I tried to use the plumbing sub-crates, but couldn't replicate everything Repository does on my own. I might take a stab at #1677 , it seems interesting and could at least reduce the absolute number of crates downloaded.

Cheers!

PS here's the stackplot of the gitoxide repo:

I have to investigate why the "cleavage line" isn't there in the original python version, which has a slightly different measurement method:

[Byron]

Thanks so much for sharing this here, it's truly amazing work!

Gitoxide truly is a special library. It’s super fast, has a ton of features and the interfaces are pretty coherent together. As an example of its superpowers, it can use Rayon to parallelize its own operations, and when unpacking compressed Git data it has access to zlib-rs, the fastest existing zlib library. It’s genuinely a shining star of the Rust ecosystem.

This made me blush ☺️, thank you!

My only question/comment is that the number of crates installed by the main gix crate seems high to new users just downloading my tool with cargo-install, even with default-features turned off. I tried to use the plumbing sub-crates, but couldn't replicate everything Repository does on my own.

The gix crate is already structured to only include the minimal amount of plumbing crates if default features are disabled, and I am very mindful about adding more dependencies. It definitely wouldn't be worth for most to try to bypass it, too, and agree that #1677 would probably have great impact to overall compile times.
Merely pulling in a lot of small gix-* crates that are parallelising well and compile quickly shouldn't be a problem though. But then again, I also didn't truly debug this to see where most time can be saved, maybe there are more opportunities beyond #1677 though.

I might also add that installing gix-of-theseus was pretty quick overall, in pure compile time, probably also because it didn't have to download more than 2 crates.

❯ cargo install gix-of-theseus
    Updating crates.io index
  Downloaded gix-of-theseus v2.0.0
  Downloaded 1 crate (331.3KiB) in 0.40s
  Installing gix-of-theseus v2.0.0
    Updating crates.io index
     Locking 260 packages to latest compatible versions
      Adding gix v0.73.0 (available: v0.74.1)
      Adding indicatif v0.17.11 (available: v0.18.2)
  Downloaded gix-archive v0.22.0
  Downloaded gix-worktree-stream v0.22.0
  Downloaded jiff-static v0.2.16
  Downloaded jiff v0.2.16
  Downloaded 4 crates (827.9KiB) in 0.49s
   Compiling proc-macro2 v1.0.103
[..]
   Compiling gix v0.73.0
   Compiling gix-of-theseus v2.0.0
    Finished `release` profile [optimized] target(s) in 18.46s
  Installing /Users/byron/.cargo/bin/gix-of-theseus
   Installed package `gix-of-theseus v2.0.0` (executable `gix-of-theseus`)

gitbutler ( next2) [$] via  took 18s

Besides that, let me CC @cruessler here who will probably find your implementation very interesting, it is still my hope we can get the best possible blame implementation into gix-blame, to eventually power the next generation of Git-detective tools :).

Last but not least, I'd love it if you could make progress on #1677, as I am very curious about the impact of… not being able to parse URLs for compile times :D.