https://nest.pijul.com/pijul/pijul
Git can be annoying to integrate into a larger system without resorting to shelling out to the Git executable. There are alternatives like libgit2 and jgit, but they only have a subset of functionality.
I've become very opinionated in my old age, and I now firmly believe that:
1. All command-line tools should be "library first, cli second".
2. All text-based formats should include a parser and formatter as a function. Never specify a text format you can't round-trip. In other words, always include an "escape" function and an "unescape" function, or better yet, a parser and serializer. Random config files in Linux are notorious for not doing this. I want to be able to parse them, modify the object in memory, and then write them back out without having to worry about how strings are quoted or dates are formatted.
3. Protocols should always come with a non-executable and machine-readable spec. Think ANTLR grammar file, Open API spec, or something. Never use English only to describe a protocol. Make sure client code can be 100% automatically generated by a tool, in multiple languages.
But git users are more familiar with porcelain so I wouldn't be surprised if they parsed that for an initial implementation.
It sounds like plumbing shouldn't break as often as you imply:
> The interface (input, output, set of options and the semantics) to these low-level commands are meant to be a lot more stable than Porcelain level commands, because these commands are primarily for scripted use.
https://schacon.github.io/git/git.html#_low_level_commands_p...
However, doesn't seem like they're nearly as rigorous as you hope.
From what I've seen, they're using the latter, but breaking changes are still introduced.
Either way, the output of UNIX-like command-line tools is inherently weakly typed and often completely unspecified.
PowerShell for comparison ships every module as both a user-interactive CLI command (with parameter tab-complete!) and as a programatically usable dynamic library. They're inherently one and the same, there's only one interface that does both. The API returns .NET objects and is strongly typed. There is no parsing step at all. If you load a given version of a library, you'll always get the expected types in the results.
Speaking of which, PowerShell uses semantic versioning for modules and can have multiple running side-by-side.
The future is here, it's just not very evenly distributed.
I have failed to use PowerShell seriously many times, I am always let down by the opaqueness of it. (Which I agree is a common complaint against bash from inexperienced users)
From looking at the implementation of the executable, I think the library could really use some higher-level constructions like `Repository` here[0], or at least some higher-level prose docs explaining how to put the pieces together manually, maybe with a disclaimer like ripgrep's backing library[1] has.
I really like what Pijul is doing from a design standpoint, but unfortunately it's far from the level of polish I would want to be able to consider it as a realistic alternative to git. If I'm going to have to put in effort to work around warts either way, I'm going to pick the tool with warts that I already know how to work around over the one where I'd have to learn from scratch and wouldn't have nearly as many resources to help me learn them.
[0]: Not sure how to link to a specific line on the Pijul hosting site, but it's in https://nest.pijul.com/pijul/pijul:main/SXEYMYF7P4RZM.W5JQA