Show HN: Gogit – Just enough Git (in Go) to push itself to GitHub

by benhoyt • 3 years ago

176 60 3 years ago

zdgeier• 3 years ago

Nice work!

388• 3 years ago

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• 3 years ago

Are you 1268? Are you creating identities on platforms by bruteforcing the lowest available cardinal? Because that is a great idea

388• 3 years ago

yes and yes :)

evanelias7• 3 years ago

In 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_plugh3• 3 years ago

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.

388• 3 years ago

not really. its littered with interfaces, in some cases many levels deep, which in Go is an anti pattern. original author clearly came from Java or some other deeply OOP language. also:

super-specific use-case

uh, "git diff" is specific?

Smaug1233• 3 years ago

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.

diarrhea2• 3 years ago

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.

388• 3 years ago

it itself does not offer itself up as a library

yeah, it does:

https://godocs.io/github.com/git-lfs/git-lfs/v3

diarrhea2• 3 years ago

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

TkTech• 3 years ago

It seems a similar story with the rest of git.

Dulwich[1] is a pure-python Git implementation that's been around for many years, meant to be used as a library. I used it a long time ago to make a git-backed wiki. There's also libgit2 which is exactly what it sounds like and it has mature Go bindings[2]. I'm sure there are more implementations.

[1] https://github.com/jelmer/dulwich [2]: https://github.com/libgit2/git2go

coryrc2• 3 years ago

IPC via return codes and parsing stdout/stderr

That's wildly different from Go's method of != nil and error strings.

benhoyt3• 3 years ago

I'm guessing you're being sarcastic. If so, it's not really a fair criticism. Go has properly-typed return values (not just parsing text from stdout) and any type can implement the error interface, allowing for error types with any custom, properly-typed attributes. You use Go's type assertion or errors.Is / errors.As to handle the latter.

_ph_• 3 years ago

The problem with the IPC approach isn't error handling - in the error case a good string is usually fine. The problem is with parsing the output of the sub process. A library can return structured data. Parsing always has the risk of format change or quickly gets very heavyweight. Both in the syntax of the output and the parsing routines. It is another good example of the SVN system, that their commands usually have the "xml" option which creates structured output in xml format. So you can use standard parsers to get robust output. This is also one thing I like about powershell, that commands can produce and pass objects instead of just writing to stdout.

CuriousCosmic• 3 years ago

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.

It's worth noting that there is currently a push to "lib-ify` git internals and it's a gradual process. I'm not actually sure how much of this work has actually made it into the tree yet but I've been seeing patchsets towards that goal on the mailing list since at least January.

strogonoff• 3 years ago

Isomorphic Git is a Git implementation purely in JS (no WASM). I wrote a minimal library to handle LFS with it, it’s not that hard, the spec is pretty small.

adrianmsmith3• 3 years ago

I always respected the fact that the authors of Subversion, right from the start, structured their software as a library, with the CLI being a user of that library.

The way IDEs and GUIs interacted with CVS was to shell out to the CLI, which inevitably had problems with filenames with spaces, parsing of error messages, etc. Subversion understood in 2000 that the things were changing, and that the CLI was only one way you'd use a VCS. People were more and more interacting with the VCS via IDEs, or via right-click menus in Windows Explorer, etc.

I felt happy knowing I'd never again have to deal VCSs via tools just shelling out to their CLI ever again. How wrong I was...

diamondo25• 3 years ago

JetBrains forgot this memo, as it requires you to configure svn.exe in order for it to work. And usually TortoiseSVN is the way to go for subversion...

alexhornby• 3 years ago

git-lfs, as in the binary, CLI application is the only (open) implementation in existence. There is nothing else.

There’s at lease one in sapling and Mononoke.

https://github.com/facebook/sapling/tree/main/eden/mononoke/...

c7DJTLrn• 3 years 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

388• 3 years ago

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.

pmarreck2• 3 years ago

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.

alex_lav• 3 years ago

I think the ultimate question for me is, does increased tedium demand/imply/require "attention", or does it just create a new opportunity for mistake? If devs are so frequently writing these "check()" style functions, are they paying attention to or ignoring errors?

lawn• 3 years ago

Being verbose and needlessly repetitive is indeed something they wanted, but it doesn't mean it's a good solution.

If something is too verbose and repetitive your brain will learn to skim over it, making it lose effectiveness while increasing the risk for bugs.

jstanley• 3 years ago

The language designers aren't the boss of you. Just because they want something doesn't mean you have to do it.

benhoyt3• 3 years ago

Putting error nil checks into a function is an anti-pattern in Go.

I assume you mean into a helper function like I've done with check()? If so, I agree with you for normal "production" Go code. But for simple throw-away scripts you don't want half your code littered with error handling, when you could just throw a stack trace.

There is no need to worry about the LOC count of your error checking code.

Well, it means some functions are more than half error handling, obscuring the guts of what a function actually does. Even the Go language designers agree that Go's error handling is too verbose, hence proposals like this from Russ Cox: https://go.googlesource.com/proposal/+/master/design/go2draf... (there are many other proposals, some from the Go team)

inb4 this ends up on pcj

im not shur wut pcj meenz

dgb232• 3 years ago

After they introduced generics I immediately wrote a generic Must function that returns the thing or panics.

There’s plenty of (pre generics) Must functions in the std lib that fo this.

adrianmsmith3• 3 years ago

Putting error nil checks into a function is an anti-pattern in Go.

What should you do instead?

Smaug1233• 3 years ago

You may have misread this. The OP means "extracting error nil checks into a function is an anti-pattern", not "your functions should not contain error handling".

amedvednikov• 3 years ago

Looks really cool!

Any chance you could add `git pull` support as well?

Smaug1233• 3 years 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• 3 years ago

Nice, I'm liking the python version too. Good stuff

Show HN: Gogit – Just enough Git (in Go) to push itself to GitHub

Related Stories