3 ms·

In truth it's a bit of a tire fire. You're better off shelling out to git in almost all cases. I tried using it to automate some simple git workflows and found

In truth it's a bit of a tire fire. You're better off shelling out to git in almost all cases. I tried using it to automate some simple git workflows and found pitfalls everywhere.

evanelias 3y ago
Sorry to hear that, but go-git is good enough to be useful to Vault, Pulumi, kubernetes/test-infra, and many other projects which directly import it. Some folks seem to expect it to be a feature-complete library-usable Go re-implementation of the entirety of Git, despite it being (afaik) largely unfunded / volunteer-driven in recent years. I don't think that's realistic. And yes in many use-cases it may indeed make more sense to shell out to `git`, there's nothing wrong with that. In any case, in my direct experience, the go-git maintainers do happily accept helpful PRs. It just seems really weird to me to see folks trash go-git, while simultaneously cheering this new gogit project which is just 400 lines and intentionally by design/scope contains only a tiny fraction of go-git's functionality.
- xyzzy_plugh 3y ago
  > go-git aims to be fully compatible with git, all the porcelain operations are implemented to work exactly as git does. It literally says this on the tin, yes. But it's not. I'm simply providing my own experience and a disclaimer. Sure, they "happily accept helpful PRs" but the code is so very complex and many paths have horrible performance that it's an incredible uphill battle. To be clear I'm not simply shitting on this library, I'm saying it's not a reasonable choice over just using git directly, and is unlikely to ever be. I haven't made any comment on TFA so while I'm not cheering it on, I do think the spirit is correct: just do the thing you need to do, don't try to be feature complete, just solve the task at hand.
  - evanelias 3y ago
    I interpret "aims to be fully compatible" as meaning the operations it implements are intended to be compatible with how Git implements those operations. I do not interpret this statement as saying they implement all features of Git. They offer a document which directly shows what is and isn't supported, and it specifically notes quite a few things that aren't supported yet: https://github.com/go-git/go-git/blob/master/COMPATIBILITY.md https://github.com/go-git/go-git/blob/master/COMPATIBILITY.m... The godoc also says right upfront it "nowadays covers the majority of the plumbing read operations and some of the main write operations, but lacks the main porcelain operations such as merges." - https://pkg.go.dev/github.com/go-git/go-git/v5#pkg-overview https://pkg.go.dev/github.com/go-git/go-git/v5#pkg-overview > I'm saying it's not a reasonable choice over just using git directly, and is unlikely to ever be. OK, that's apparently true for your use-case. But again, what go-git implements is directly useful to a number of very popular projects, as well as literally two thousand less popular ones. I find the exported functionality to be high quality, at least for my own use-case. I'm not commenting on the code quality. If I need a shed for bikes, and someone is giving out free but ugly bikesheds, I'm thankful. I don't complain about the color of the bikeshed.
    - xyzzy_plugh 3y ago
      It's useful for toy projects or narrow stateless use cases, like testing or fetching something one time, like in Terraform, but as soon as you have to deal with real world scenarios related to actual distributed version control, the wheels completely fall off. Can you use it to implement a git remote? No. What about to write some commits? Also no. What about a read-only client? Nope. It only works well if you have a narrow use case, and only works predictably if you are in full control of the repository being interacted with. Otherwise it is simply going to cause more pain than just using git directly. Look at the open issues, the open issues related to it in projects that depend on it. You clearly have a horse in this race and that's fine, if it works for you, great. But I don't recommend it. And no amount of lobbying on your part is going to alter that reality. If you're doing serious things, use git directly, and if you're not, it's probably simpler to write it yourself. And lastly, the exported functionality is not high quality. It performs poorly in many scenarios where shelling out to git does not, and it breaks with any sort of complicated set up.

In truth it's a bit of a tire fire. You're better off shelling out to git in almost all cases. I tried using it to automate some simple git workflows and found pitfalls everywhere.

evanelias 3y ago

Sorry to hear that, but go-git is good enough to be useful to Vault, Pulumi, kubernetes/test-infra, and many other projects which directly import it. Some folks seem to expect it to be a feature-complete library-usable Go re-implementation of the entirety of Git, despite it being (afaik) largely unfunded / volunteer-driven in recent years. I don't think that's realistic. And yes in many use-cases it may indeed make more sense to shell out to `git`, there's nothing wrong with that. In any case, in my direct experience, the go-git maintainers do happily accept helpful PRs. It just seems really weird to me to see folks trash go-git, while simultaneously cheering this new gogit project which is just 400 lines and intentionally by design/scope contains only a tiny fraction of go-git's functionality.

xyzzy_plugh 3y ago
> go-git aims to be fully compatible with git, all the porcelain operations are implemented to work exactly as git does. It literally says this on the tin, yes. But it's not. I'm simply providing my own experience and a disclaimer. Sure, they "happily accept helpful PRs" but the code is so very complex and many paths have horrible performance that it's an incredible uphill battle. To be clear I'm not simply shitting on this library, I'm saying it's not a reasonable choice over just using git directly, and is unlikely to ever be. I haven't made any comment on TFA so while I'm not cheering it on, I do think the spirit is correct: just do the thing you need to do, don't try to be feature complete, just solve the task at hand.
- evanelias 3y ago
  I interpret "aims to be fully compatible" as meaning the operations it implements are intended to be compatible with how Git implements those operations. I do not interpret this statement as saying they implement all features of Git. They offer a document which directly shows what is and isn't supported, and it specifically notes quite a few things that aren't supported yet: https://github.com/go-git/go-git/blob/master/COMPATIBILITY.md https://github.com/go-git/go-git/blob/master/COMPATIBILITY.m... The godoc also says right upfront it "nowadays covers the majority of the plumbing read operations and some of the main write operations, but lacks the main porcelain operations such as merges." - https://pkg.go.dev/github.com/go-git/go-git/v5#pkg-overview https://pkg.go.dev/github.com/go-git/go-git/v5#pkg-overview > I'm saying it's not a reasonable choice over just using git directly, and is unlikely to ever be. OK, that's apparently true for your use-case. But again, what go-git implements is directly useful to a number of very popular projects, as well as literally two thousand less popular ones. I find the exported functionality to be high quality, at least for my own use-case. I'm not commenting on the code quality. If I need a shed for bikes, and someone is giving out free but ugly bikesheds, I'm thankful. I don't complain about the color of the bikeshed.
  - xyzzy_plugh 3y ago
    It's useful for toy projects or narrow stateless use cases, like testing or fetching something one time, like in Terraform, but as soon as you have to deal with real world scenarios related to actual distributed version control, the wheels completely fall off. Can you use it to implement a git remote? No. What about to write some commits? Also no. What about a read-only client? Nope. It only works well if you have a narrow use case, and only works predictably if you are in full control of the repository being interacted with. Otherwise it is simply going to cause more pain than just using git directly. Look at the open issues, the open issues related to it in projects that depend on it. You clearly have a horse in this race and that's fine, if it works for you, great. But I don't recommend it. And no amount of lobbying on your part is going to alter that reality. If you're doing serious things, use git directly, and if you're not, it's probably simpler to write it yourself. And lastly, the exported functionality is not high quality. It performs poorly in many scenarios where shelling out to git does not, and it breaks with any sort of complicated set up.