- rant mode on

Having used most SCM since RCS days, I get to differ, but since I am left without another option, so just like with C and JavaScript, I suck it up and get the job done by whatever means.

- rant mode off

Thanks for bringing a bit more of security into the IT world with a Go version though.

Why would a different CLI (presumably still using libgit2) improve security? Especially if it's installed like this: curl -sf https://gobinaries.com/chriswalz/bit | sh;

> Especially if it's installed like this: curl -sf https://gobinaries.com/chriswalz/bit | sh

What's wrong with this? It's no worse than git clone && make

or any of the other hundred incantations of executing code from the web.

It's much worse. At least with `git clone` you can verify that the code you're building matches something you trust. You have to trust the code and your make tool. You can inspect the code if you're concerned and validate that it's going to do what it says.

It's true that the vast majority of the time a "curl | sh" works fine and does just what you expect it to do, but that's not really the point. The point is that you have no idea what that script your piping will do. You also have no idea whether in this case the binary it fetches is actually built from the code the service says it is; downloading the script first and inspecting it is a good idea, but still not as good as building directly from the code.

This is why we see people do things like publish a hash sum alongside binaries they offer, or use a digital signature. Then we can at least verify that a binary matches what the author says they released, or better yet ensure that the binary was produced by a trusted source.

> You can inspect the code if you're concerned and validate that it's going to do what it says.

You can just not pipe the curl script to shell and inspect it [0]. Executing that is no worse than executing a random make command or `brew install`

> downloading the script first and inspecting it is a good idea, but still not as good as building directly from the code

No, you need to inspect the code too if you're that worried. I can write a makefile that just does this: build: curl http://example.com -o bad.txt && cat bad.txt

Either you're actually vetting what you run on your machine, or you're not. curl | sh isn't any worse than git clone && make.

> This is why we see people do things like publish a hash sum alongside binaries they offer, or use a digital signature. Then we can at least verify that a binary matches what the author says they released, or better yet ensure that the binary was produced by a trusted source.

So just publish the hash/signature next to "install instructions" that contains the curl command, and let the user verify the hash themselves. Again, that has nothing to do with the install method.

[0] https://pastebin.com/atHcYR8x

First: I apologize for not reading your original post closely enough. I agree that "curl | sh" is no worse than "git clone && make"; I think both are terrible. I will say that I can't recall ever seeing anyone recommend "git clone && make".

It sounds like we agree that blindly downloading code and building/executing it is a bad idea. That's all I was trying to assert.

There's a spectrum of safe/acceptable between "download a random binary" and "build yourself, from trusted source". I think "curl | sh" and "git clone && make" are just one step above "download a random binary" on that spectrum. We can and should do better than that.

It doesn’t use libgit2 it shells out to git. So it doesn’t improve security.

It still does, by adding yet another layer, written in a memory safe language.

Just like a castle with a water pit can still be conquered, but it takes a bit more effort for achieving it.

I do not care about memory safety only, I would be pissed if it removed my files, for example. :D Security is too broad a term anyways, hence this thread.

Depends entirely on threat model. More code is more surface area for vulnerabilities to be found.

Memory safety?

And all of those commands have an incompatible syntax.

SVN is much better in these regards.

Yes! A git cli with a good syntax which is the same for every command would be useful. It would not have to do every nifty git feature, just uses a senseful subset: git push/bull branching/merging/rebasing and add some nifty common problems like delete file from history, remove last x commits already pushed etc.

The most popular git questions on stackoverflow tells a story on which tasks are more complex on git because you have to know all the internal tricks.

https://github.com/tj/git-extras/blob/master/Commands.md does it pretty well. Everything you've listed is covered there I think.

Thanks, this is really awesome!

I just personally use BFG to scrub files from history https://rtyley.github.io/bfg-repo-cleaner/

Got would have been a better name.

It includes Go and sounds like Git.

There is already a git compatible VCS called got, it is developed from some OpenBSD pople.

https://gameoftrees.org/

Thanks for making such a cool tool. Does it intergrate anything like gitflow ?

Thanks! Right now it has no special configuration or setup as I want it to be as easy to install as possible (simply run a curl command or go command). Perhaps down the road it will – totally depends on what direction bit will go based on feedback from users :)