[schacon]

I would also be interested.

I haven't dug into this at all yet, nor have I tried to optimize the size (or really, anything else).

However, the library part will be less than half of this - a lot of code is spent on the CLI specific stuff and would not be part of the library, which is mostly what I care about for the purposes of this project. The CLI part is just to try to prove the point that it actually does what Git does. The library part is what might be useful in that nothing else exists that does all of the things that it does (provide a reentrant linkable library that is feature complete with Git).

[andwur]

Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly.

Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB.

[1] https://github.com/gitbutlerapp/grit/blob/main/grit-lib/src/...

[schacon]

Nice, I haven't dug into this yet. If we can get this usable, it would be pretty cool to have a small lib or a series of much smaller, directed libs that can be used by simpler interfaces and you can just compose the parts you need.