4 ms·

Not sure what you expected? That's the case for all git clients (is there any using libgit?) and almost certainly the right thing to do

ultramann 1y ago
I'm aware of go-git [0] which > 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. [0] https://github.com/go-git/go-git https://github.com/go-git/go-git
- throwaway127482 1y ago
  I've used it - it's lacking a ton of features. Another commenter in this thread said it's very slow compared to the git CLI, which is not surprising given that git is written in C.
  - throwaway894345 1y ago
    I’ve used it for a production service. I thought it was surprisingly robust/featureful. There was one issue I ran into, but IIRC it was a limitation in the library’s filesystem abstraction, not a missing feature.
- notnmeyer 1y ago
  it’s slow, not great. at a previous place we used go-git and wound up switching to just shelling out to git.
johnisgood 1y ago
I would have used libgit2 myself in any languages. If bindings do not exist, I would have made the bindings first. There is no way I would have called out to an external program. Someone mentioned https://github.com/go-git/go-git 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.
- throwaway894345 1y ago
  Binding to C in Go is a bad idea typically. There’s performance overhead, but more importantly your library (and everything downstream) also loses the ability to do nice things like fast compile times or easy cross compilation. You also likely introduce a runtime dependency on libc if not libgit2, so you have some DLL hell to deal with.
  - johnisgood 1y ago
    Is the performance overhead significant? Is it worse than calling out to an external program? Are there any benchmarks on this?
    - 9rx 1y ago
      > Is the performance overhead significant? 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.
      - johnisgood 1y ago
        Yeah, but for this project, why would you choose (as others stated they would or prefer) to call out to an external program instead of using https://github.com/libgit2/git2go https://github.com/libgit2/git2go (libgit2, FFI) for example? For what it is worth, there is also a pure Go implementation: https://github.com/go-git/go-git https://github.com/go-git/go-git (pure Go). 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.
Zambyte 1y ago
Jujutsu (jj) was using libgit, but they migrated away to wrapping the git cli several versions ago.

ultramann 1y ago

I'm aware of go-git [0] which > 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. [0] https://github.com/go-git/go-git https://github.com/go-git/go-git

throwaway127482 1y ago
I've used it - it's lacking a ton of features. Another commenter in this thread said it's very slow compared to the git CLI, which is not surprising given that git is written in C.
- throwaway894345 1y ago
  I’ve used it for a production service. I thought it was surprisingly robust/featureful. There was one issue I ran into, but IIRC it was a limitation in the library’s filesystem abstraction, not a missing feature.
notnmeyer 1y ago
it’s slow, not great. at a previous place we used go-git and wound up switching to just shelling out to git.

johnisgood 1y ago

I would have used libgit2 myself in any languages. If bindings do not exist, I would have made the bindings first. There is no way I would have called out to an external program. Someone mentioned https://github.com/go-git/go-git 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.

throwaway894345 1y ago
Binding to C in Go is a bad idea typically. There’s performance overhead, but more importantly your library (and everything downstream) also loses the ability to do nice things like fast compile times or easy cross compilation. You also likely introduce a runtime dependency on libc if not libgit2, so you have some DLL hell to deal with.
- johnisgood 1y ago
  Is the performance overhead significant? Is it worse than calling out to an external program? Are there any benchmarks on this?
  - 9rx 1y ago
    > Is the performance overhead significant? 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.
    - johnisgood 1y ago
      Yeah, but for this project, why would you choose (as others stated they would or prefer) to call out to an external program instead of using https://github.com/libgit2/git2go https://github.com/libgit2/git2go (libgit2, FFI) for example? For what it is worth, there is also a pure Go implementation: https://github.com/go-git/go-git https://github.com/go-git/go-git (pure Go). 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.

Zambyte 1y ago

Jujutsu (jj) was using libgit, but they migrated away to wrapping the git cli several versions ago.