7 ms·
Show HN: Gogit – Just enough Git (in Go) to push itself to GitHub
- zdgeier 3y agoNice work!
- 38 3y agoI have been wanting something like this, but with a few more features such as "git diff". I took a crack at it, but the popular (and maybe only) Go Git implementation has some issues: https://github.com/go-git/go-git/issues/700 https://github.com/go-git/go-git/issues/700
- anacrolix 3y agoAre you 1268? Are you creating identities on platforms by bruteforcing the lowest available cardinal? Because that is a great idea
- evanelias 3y agoIn my opinion github.com/go-git/go-git is a very high-quality project. Just because it doesn't solve some super-specific use-case that you have, doesn't mean the project isn't good. It's open source, have you tried opening a pull request to solve your own issue?
- xyzzy_plugh 3y agoIn 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 agoSorry 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 agoI 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.
- Smaug123 3y agoPersonally I soldiered on to to the point of being able to extract objects from packfiles, before I realised just how monstrously and tediously complex `git rev-parse` is, and gave up. It's foundational to pretty much every porcelain command, so it's not really something you can leave out if you want a semi-functioning `git`. See https://git-scm.com/docs/git-rev-parse#_specifying_revisions https://git-scm.com/docs/git-rev-parse#_specifying_revisions and https://github.com/git/git/blob/ee48e70a829d1fa2da82f14787051ad8e7c45b71/refs.c#L732 https://github.com/git/git/blob/ee48e70a829d1fa2da82f1478705... ; `git` really is an edifice.
- diarrhea 3y agoThe other day I was trying to work with git LFS. I was very surprised to find out git-lfs, as in the binary, CLI application is the only (open) implementation in existence. There is nothing else. And even it itself does not offer itself up as a library; so even native Go code (the implementation language) has to fall back to shelling out to the CLI git extension! Not even bindings are possible. Such a painful loss of interoperability: IPC via return codes and parsing stdout/stderr. It seems a similar story with the rest of git. I have hopes for gitoxide aka gix, and think the approach of library-first is correct going into the future. A CLI is then simply a thin wrapper around it, mapping argv to library operations basically.
- 38 3y ago> it itself does not offer itself up as a library yeah, it does: https://godocs.io/github.com/git-lfs/git-lfs/v3 https://godocs.io/github.com/git-lfs/git-lfs/v3
- diarrhea 3y agoI don’t know what that is, but their docs very prominently and strongly say this: > However, we do not maintain a stable Go language API or ABI, as Git LFS is intended to be used solely as a compiled binary utility. Please do not import the git-lfs module into other Go code and do not rely on it as a source code dependency. https://github.com/git-lfs/git-lfs#limitations https://github.com/git-lfs/git-lfs#limitations
- 38 3y ago[flagged]
- yjftsjthsd-h 3y agoThat you technically have the ability to call into an internal module does not in any way constitute it "offering itself up as a library", and doesn't make it effectively useful in that way.
- 3y ago
- lopkeny12ko 3y ago[flagged]
- tedunangst 3y agoI don't think you're expected to use a git client that's missing just about every wanted feature.
- lopkeny12ko 3y agoExactly why I find this article so confusing.
- Matl 3y agoWhy do you comment on Hacker News? After all there are many other commenters with insightful comments people presumably want to read. If you answered; 'for fun', 'to learn something' etc. then you know why this blog post exists.
- zeroxfe 3y agoFeels like you're missing the spirit of the article. Nobody's advocating it as a git replacement -- the author is just posting thoughts about something they built.
- Chico75 3y agoNowhere does the author advocates for using its tool instead of git. Not everything is about self-promotion, sometimes it's simply knowledge sharing.
- egypturnash 3y agoThe second paragraph explains why this exists, and it's not to provide a useful implementation of Git. > I wanted to compare what it would look like in Go, to see if it was reasonable to write small scripts in Go – quick ’n’ dirty code where performance isn’t a big deal, and stack traces are all you need for error handling. It's a toy problem that's just big enough to be interesting. Comparing it to Hoyt's earlier Python implementation of the same problem lets him evaluate how Go would fit into a certain place in his development workflow.
- c7DJTLrn 3y ago>The verbosity of Go’s error handling has been much-maligned. It’s simple and explicit, but every call to a function that may fail takes an additional three lines of code to handle the error Putting error nil checks into a function is an anti-pattern in Go. There is no need to worry about the LOC count of your error checking code. inb4 this ends up on pcj
- 38 3y agoagreed. when I see people talking about LOC my eyes roll. its verbose for a reason, the language designers WANT YOU to pay attention to the errors, not ignore them.
- pmarreck 3y agoThat's exactly why every other language took the wiser decision of actually having runtime errors. To force you to pay attention to them before your application state went into an unknown configuration, thus making it nearly impossible to troubleshoot or even pretend to be deterministic. I still have no idea how any programmer thinks this is OK. Nondeterminism and unknown/un-considered application state are literally the source of all bugs. I much prefer (and honestly believe it makes a ton more sense) to do what Erlang/Elixir does, which is to fail, log, and immediately restart the process (which only takes a few cycles due to the immutability-all-the-way-down design). If you hit my Phoenix application with a million requests in 2 seconds and each throws a 500 error, my webserver will keep chugging along, while every other technology's webserver will quickly exhaust its pool of ready-to-go webserver processes and fall over like a nun on a bender.
- Kwpolska 3y ago> every other technology's webserver will quickly exhaust its pool of ready-to-go webserver processes and fall over like a nun on a bender Most other technologies don't use one process per request, but instead have a single server process which handles all exceptions that come out of a request by returning 500 without crashing the server.
- 3y ago
- amedvednikov 3y agoLooks really cool! Any chance you could add `git pull` support as well?
- Smaug123 3y ago`git pull` is not easy! It implies implementing a merge algorithm, for example. (One could half-ass this by only implementing fast-forward merge, I suppose.)
- JaDogg 3y agoNice, I'm liking the python version too. Good stuff
- LiamCooper234 3y ago[dead]