[Aperocky]

> A pretty fun experiment and I think we can shape this into something truly useful to the whole community.

Agree with first half of this sentence, we should all have fun with experiments.

> It was never based on a linkable and reentrant library, but instead on a "Unix" philosophy of chaining together simpler commands, which means that it's difficult to use it in long running processes without fork/exec overhead for everything.

Ahhh now we have philosophical disagreement in the only place in the entire article that says "why". Unix is a feature, it's arguably more important in current time: https://aperocky.com/blog/post.html?slug=unix-philosophy-age...

[Levitating]

You cut that citation conveniently short.

> It was never based on a linkable and reentrant library, but instead on a "Unix" philosophy of chaining together simpler commands, which means that it's difficult to use it in long running processes without fork/exec overhead for everything.

[Aperocky]

Added it in full. It still squarely falls under "this is for fun/are you seriously doing this for this purpose" territory for me.

git operate on the filesystem level, the unix behavior is just getting buried. You cannot rewrite git into a linkable library and decide it's now not unix. It's entire behavior is unix, which is why it's awesome.

[schacon]

My intent with this project is not to replace Git in any way. I don't care about the CLI part of this project.

The point is to provide a feature-complete reentrant linkable library. Even if it's an ugly and slow one, this is still the only one thing that exists that covers those points - Gitoxide and libgit2 are both awesome but they are not feature complete.

[lelanthran]

> The point is to provide a feature-complete reentrant linkable library.

If that was the goal, why change the license?

[MBCook]

Isn’t git already just an interface over libgit? How is that different?

[tredre3]

Git is famously not built around a (reusable) library, hence why we have things like libgit2 (unrelated to git) and why any porcelain on top of git has to resort to calling the binary and parsing its text output.

[MBCook]

I was not aware of that. I knew it was split but didn’t know that split wasn’t useful to others.

Thanks.

[schacon]

libgit.a isn't reentrant. It will call `die()` on many errors. If you link to it in a long running binary, it will kill your process on error.

Libgit2 is meant to address this and I was heavily involved in the development of that project 15 years ago. It's great but it's not feature complete and it's development is also completely separate from git development, so it's out of sync and constantly struggling to keep up.