> cmd := c.execCommand("git", "branch", "--format", "%(refname:short)")
oh my god. you have just wrapped standard git CLI. well, this is dissapointing.
oh my god. you have just wrapped standard git CLI. well, this is dissapointing.
> aims to be fully compatible with git, all the porcelain operations are implemented to work exactly as git does
written in pure go, therefore with a go native api.
I've never tried to use it, but it does look quite impressive to me.
Someone mentioned https://github.com/go-git/go-git. I would have definitely used it unless there are better alternatives. If - as someone who claimed - it turns out it is slow, I would have created my own bindings to libgit2 still, most likely.
How do you define significant? It is noticeable as compared to C. It is nothing compared to Python.
> Are there any benchmarks on this?
You will see an additional ~20ns per call (assuming the gc compiler; tinygo, for example, can call C functions as fast as C can). In other words, you're not ever going to notice unless you're making millions of calls in a hot loop. The bigger problem in a highly concurrent environment is that blocking C functions can start to mess with the scheduler if they are slow to return. You, again, would never notice in a program of this nature, though. The feature is there to be use. It being a "bad idea" is nonsense.
Some added pain in compilation is, fairly, a tradeoff to consider. But that's just because C compilers, for the most part, aren't very good. It is not like those problems go away if you use C instead.
Keep in mind the initial comment, which is "I would have used libgit2 myself in any languages.", and they claimed it is a bad idea due to performance, as opposed to calling out to an external program.
Which, as before, is nonsense.
You want more nonsense...?
Many people has said they are thankful it calls out to "git" instead of using FFI, which I think is weird, but then there are others who go ahead and say that it is a worse thing to do, and I want people to know that no, it is not.
I chose to shell out to git because it's fast, stable, and has great cross-platform support. Tools like go-git and libgit2 are interesting (and I’ve looked into them), but they come with their own tradeoffs like performance, features, and build complexity.
That said, I totally get the curiosity — thanks for the discussion!
What's in it for them?
The bad idea claim was principally about breaking cross and static compilation.
Which is especially funny as using go-git (which is known to be slow) and shelling out to git are apt to bring even greater performance overhead. As always, don't assume – measure!, but if we have to play the odds for the sake of an internet comment, libgit2 is likely to be the most performant option reasonably available, if there is some reason to think that performance is of concern here.
Added complexity in compiling is a tradeoff to consider, of course, but "bad idea" is also nonsense there. It requires a different set of priorities, but those priorities may very well be exactly what a project needs. — And maybe not even. The earlier comment brought a lot of assumptions without offering any background. There are theoretically other options available for libgit2. For example, using the Wasm build. While others have had success using Zig as the C-side compiler, which doesn't have all the messy baggage legacy compilers tend to carry (e.g. poor cross-compilation support).
Yes, measurement may offer reason why those are not suitable options, but missing in the comment is the measurement, or even what is trying to be measured! Instead, we got something that appears to be copy and pasted straight from a Rust advertisement.
Yes, there are cases in which CGo’s tradeoffs are appropriate, but you’re rebutting my claim that CGo is a bad default, so you need to show that CGo is appropriate in the default case (you went so far as to call it “nonsense”), not merely that there exists some project for which CGo’s tradeoffs are appropriate.