SmackerNews

0 points · 0 comments · 10 days ago · schacon

news.ycombinator.com/item?id=48470604

I addressed this in the post, but Git has no linkable library and never has. If you want to do even something small, you need to fork/exec a process and communicate with it via stdin/out. Or completely reimplement it and all of the edge cases - for example, reading even one object can be either loose (easy) or in a packfile (much more difficult). Reading a reference (what SHA does a branch point to) can be in a loose file, a packfile, or a reftable. etc.

There is no way anyone would ever use this for it's CLI - it will almost certainly always be slower and worse in every way, even if I get it stable (which it's currently not). You can use libgit2 (a project I also helped kickstart), or Gitoxide (a project GitButler also currently helps drive) - they are faster and better in nearly every way, but they are not feature complete.

This isn't for the person using Git. This is for someone trying to build a tool that wants to use parts of Git, which is different.

eminence3210 days ago
But libgit2 exists, right? It may not have 100% feature parity with git, but that's a linkable library that gives you a lot of functionality when working with git repos.
gritzko10 days ago
Nice experiment, but a bit expensive.
I work on Beagle, a git-compatible SCM [1]. I use ABC, Abstractionless C [2] dialect with slices, optional range checking, etc. So far, memory safety was the least of my concerns, frankly. Most of the thorny issues would be equally thorny in Rust (e.g. right now: reflog zeroed when VM ran out of disk space; must be some state machine issue or an OS level glitch). Also, forking off a C process (no runtime) is cheap enough that you actually want to do that more.
But, those are all technicalities. The key issue I see with the approach: the data structures and algos of git have been fanatically fine tuned for that particular application with those particular usage patterns. By very sophisticated low-level C programmers. So, quite likely, any other app/lib working with that store will always be a suboptimal fit. I would recommend read-only access only, esp for LLM code.
Meanwhile, git's underlying data model (blobs/trees/commits) is very simple and very much internet-standard level. Decoupling at that interface is so much easier with so much less issues looming.
May look differently from your vantage point though.
[1]: https://github.com/gritzko/beagle
[2]: https://replicated.wiki/blog/abc
pramodbiligiri9 days ago
I hadn’t heard of libgit2. I wish more applications would expose library-style access, preferably available across different languages!
May not work for apps that want to launch their own threads and processes. But for almost everything else, I prefer function calls to launching processes, managing their lifecycle, communicating via stdout etc. If I wanted to do that, I’d be writing Bash ;)
usernametaken2910 days ago
This isn't for the person using Git. This is for someone trying to build a tool that wants to use parts of Git, which is different.
I’m going out on a limb here but I’ll say that you are over engineering for the wrong problems. I’ve done it before, I tried libgit for some use case. At the end of the day it really is much simpler to use git. If you don’t want git at runtime use something like the git-gradle-properties plugin or the likes for your build system of choice. I really can’t think of a super duper use case where forking processes is a massive enough issue that I’d want to instead port over all of git to another language. Git for the most parts also offers a wide variety of export formats such that you get machine readable output too. If you really really need to fiddle with its internals, git pack lets you browse through the index fairly well. Again, my humble opinion, but you’re trying to solve the wrong problems

news.ycombinator.com/item?id=48470604