git-salt-box VS libgit2

I started going down this route [0], but I very quickly realised the additional overhead of the tooling was not very user friendly. In the end, I'm trying to write a custom git remote which will encrypt everything, similar to how keybase works.

Internally, the idea is to just encrypt all the git objects, one per file, and store those in a git repo. It could also be stored in S3, as storing it in a repo doesn't help, but Git Repos have the least vendor lock-in.

- [0] https://github.com/GitJournal/git-salt-box

Everything that is replicated on the network is stored as a Git object, using the libgit2[0] library. This library uses hardened SHA-1 internally, which is called sha1dc (for "detect collision").

[0]: https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b...

This is delightful and I can't wait to try it out. Right now, the libgit2 project (https://github.com/libgit2/libgit2) has a custom HTTP git server wrapper that will throttle the responses down to a very slow rate. It's fun watching a `git clone` running over 2400 baud modem speeds, but it's actually been incredibly helpful for testing timeouts, odd buffering problems, and other things that crop up in weird network environments.

I'd love to jettison our hacky custom code and use something off-the-shelf instead.

I've built a UI on top of libgit2 and I wish that this blog post expanded on which new features are missing (sparse checkout?).

To quote: "The migration to Git Executable will allow us to resolve long-standing issues with GitKraken Client, such as poor LFS performance, SSH configuration support and many other features/performance improvements."

I agree on LFS performance on Windows. SSH config support is a pain due to libssh2 but openssh support is on the way (https://github.com/libgit2/libgit2/pull/6617).

There are many cons to using the Git executable itself (parsing output, error reporting, version handling). Seems to me that there's more to this?

I'm curious about the license change? This is an executable is it not? Invoking it as a separate process does not require you make the software calling it GPL so switching to MIT should have no affect in the common case.

If the authors really wanted a more permissive license, then instead of relicensing from AGPL to MIT they should have gone AGPL with linking exception. An example of a project that does this is libgit2 [1]. This licensing is more permissive but still permits the author to sell commercial licenses to those making closed-source code changes.

[1] https://github.com/libgit2/libgit2#license

Using libxlsxwriter and libgit, it's straightforward -- just putting the equivalent of git shortlog and lines added and removed into a line of cells.