[HN Gopher] Show HN: Gogit - Just enough Git (in Go) to push its...
___________________________________________________________________
Show HN: Gogit - Just enough Git (in Go) to push itself to GitHub
Author : benhoyt
Score : 55 points
Date : 2023-07-29 20:34 UTC (2 hours ago)
(HTM) web link (benhoyt.com)
(TXT) w3m dump (benhoyt.com)
| Smaug123 wrote:
| Personally 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 and
| https://github.com/git/git/blob/ee48e70a829d1fa2da82f1478705... ;
| `git` really is an edifice.
| diarrhea wrote:
| The 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 wrote:
| > it itself does not offer itself up as a library
|
| yeah, it does:
|
| https://godocs.io/github.com/git-lfs/git-lfs/v3
| diarrhea wrote:
| I 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
| 38 wrote:
| > I don't know what that is
|
| its a standard output from `go doc`, rendered as HTML. if
| you dont recognize that, then you aren't really in a
| position to be commenting on the topic. nothing is stopping
| anyone from pinning to a tag:
|
| https://github.com/git-lfs/git-lfs/tags
|
| or even a commit and relying on a specific version of the
| software. yes upgrades might be painful but a module IS
| available.
| IggleSniggle wrote:
| It is a module. It is available. It does not offer itself
| up as a library.
| 38 wrote:
| > It is a module.
|
| > It does not offer itself up as a library.
|
| in Go code, those are the same thing.
| IggleSniggle wrote:
| A library and a module are the same. Having an open and
| available module does not make it "offered up as a
| library," was the point I was trying (and failing,
| evidently), to make.
| Brian_K_White wrote:
| You made the point perfectly. So did the docs in the
| first place. It's not on you that someone decides not to
| agree the sky is blue because they use their own
| definition of blue.
| yjftsjthsd-h wrote:
| That 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.
| zdgeier wrote:
| Nice work!
| c7DJTLrn wrote:
| >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 wrote:
| agreed. 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 wrote:
| That'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.
| lopkeny12ko wrote:
| Why would someone use this instead of git? The value add is not
| clear to me.
|
| > This is going to be a short section, because I don't care about
| speed in this program, and the Go version is likely as fast or
| faster than the Python version.
|
| That's...fine I guess, but it is disingenuous to compare the
| performance of this git client to another git client written by
| the same author but in a different language. As a reader and
| someone trying to understand how and why gogit would fit into my
| development workflow, I don't care how it stacks up against
| "pygit," I care how it stacks up against _git_.
|
| > Conclusion > When used with panic-based error handling, Go is
| good for writing quick 'n' dirty command line scripts.
|
| Decent conclusion for the author himself, but no one else cares--
| the question of "why should someone migrate to this over git?" is
| still painfully unanswered.
| patmorgan23 wrote:
| People build things for practice all the time and then write up
| their experience and what they learned.
| tedunangst wrote:
| I don't think you're expected to use a git client that's
| missing just about every wanted feature.
| lopkeny12ko wrote:
| Exactly why I find this article so confusing.
| Matl wrote:
| Why 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 wrote:
| Feels 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 wrote:
| Nowhere does the author advocates for using its tool instead of
| git. Not everything is about self-promotion, sometimes it's
| simply knowledge sharing.
| egypturnash wrote:
| The 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.
| 38 wrote:
| I 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
| anacrolix wrote:
| Are you 1268? Are you creating identities on platforms by
| bruteforcing the lowest available cardinal? Because that is a
| great idea
___________________________________________________________________
(page generated 2023-07-29 23:00 UTC)