I read through the docs of pygit2, how is it too low level compared to using direct console output?

if you need complex workflows, couldn't they be built over the convenience of the library?

I recommend wrapping the git cli commands using subprocess, using porcelain output modes etc, and parsing the output.

We have had stability problems with GitPython (which wraps gitdb). On Linux gitdb does clever things with sliding mmap, which caused some crashes (in a multi threaded environment), and I found simple race conditions in the code for writing loose objects, which is about as simple an operation as can be, so I lost faith with it. I do use gitdb in one read-only single-threaded system; it's undoubtedly fast.

The biggest issues with git libraries are around the complexity of git configurations. Any independent reimplementation is probably going to support the most common 99% of features but that 1% always comes back to bite you! We use a lot of git features in service of a gigantic monorepo, like alternates and partial clones and config tricks.

If we use command-line git we get 100% compatibility with all git configuration and ODB features, and it's hard to ensure that with an independent git implementation (even libgit2).

When you say "that solution doesn't scale well" - we have made it scale. git itself scales well for operations it can perform natively, you just have to use the features effectively, often the high-level operations but sometimes lower-level commands like git cat-file --batch, git mktree --batch, etc. It's not as fast as gitdb but fast enough, and I can have high confidence that I can write something once and it won't break or cause problems later.

Dulwich is decent. Has some good porcelain functions. But it's organized kind of weird. I sort of recall it's the only one that isn't a wrapper on the git CLI?

Anyway, they all kind of suck in my experience.

https://github.com/gitpython-developers/gitdb

With no more details? I'd go with Dulwich. libgit2 is overly picky about inputs and can't be hacked apart at all, and this affects its bindings too. I recently found myself monkey-patching Dulwich to allow otherwise-forbidden characters in refs, and this would have been fundamentally impossible with anything on top of libgit2.

Honestly if you already know all the git commands? I’d use sh

I usually use subprocess. Python has a very nice API for calling subprocesses.

I used pygit2 a few years ago and it was easy. Can’t complain.

Sounds like pygit2 is the move until dulwich has a bit more support.