Game of Trees: A Version Control System for OpenBSD | Hacker News Reader

Game of Trees: A Version Control System for OpenBSD

gameoftrees.org

114 pointsLaSombra40 comments

>its target audience are OpenBSD developers

I'm a huge fan of OpenBSD and all of their efforts but the single point that makes me most in awe of them is the effort and willingness to dogfood. That is the heart and soul and the essence of what makes FOSS powerful. Make what you want to use.

While some may argue about re-inventing the wheel, the OpenBSD team has time after time shown that their implementation of $thing is better then the original it intends to replace.

Please continue fighting the good fight, I appreciate it.

I love the OpenBSD philosophy of simplicity and correctness. Plus the devs are one of the few people who actually treat incomplete or incorrect documentation as a bug. The OS is one of the easiest to set up, use, and modify. I ran OpenBSD for a long-time on my desktop and it always was a joy to use. I eventually switched back to Arch Linux due to lack of software support and subpar performance.

Going back was really painful, Linux, to put it bluntly, is a hot mess. Documentation is terrible, systemd is annoying, and the gnu userland is bloated. It’s often unclear what the kernel supports and does not support. With OpenBSD it is very clear, every driver has a man page and you don’t have to guess what hardware the OS supports.

> I eventually switched back to Arch Linux due to lack of software support and subpar performance.

> Going back was really painful, Linux, to put it bluntly, is a hot mess.

You basically answered yourself. This is the trade-off: quality vs quantity.

This is not a flame-starter, its an observation of mere facts.

Shows the value of having consistent goals and values in software development. Their focus on simplicity and clarity is inspiring.

The article states that Got will use unveil and pledge [1] to harden to codebase. This is not supported in linux, so it's unlikely that ports with similar guarantees will be straightforward. It will not replace git in general. [1] https://www.openbsd.org/papers/BeckPledgeUnveilBSDCan2018.pd...

Newbie question: For porting to Linux, can't you just remove (#ifdef out, or something) the pledge and unveil calls? You would no longer get the guarantees, but aren't these similar to assertions in that once you have a well-tested program you can have some certainty that you wouldn't violate the pledges?

The goal of something like pledge/unveil is to harden a carefully written program from being exploited, so it has a role to play at runtime. Asserts are used for program invariants, so checking them at runtime is less important.

So the big problem with ifdefing them out is that you no longer get these guarantees. Linux has seccomp that is similar in functionality, so the guarantees can be ported over - it's just going to take effort.

seccomp doesn't support file paths, while pledge and unveil do. That makes a huge difference.

This is great. I've contributed a bit to the OpenBSD kernel and core user space, but CVS is so much trouble (especially for those of us who are not core developers with access) that's it kept me away from fixing more things because of all the extra CVS-created work.

If they switch to something from this millennium (which they now seem to be doing!) then I could help do more. This may tip me over to running OpenBSD full time on my upcoming laptop.

The name though. Game of Trees? Sigh. Pop culture reference, really? This will not age well. I guess they can just drop the expansion, but then we'll have great sentences like "I got got running for my project this weekend".

Naming things: It's hard, but that's no excuse to skip the hard work and cause decades of annoyance.

The man page(1) provides a good overview. Imagine a git backend with a cvs/svn front-end (which ought to make Linus Torvalds kill himself(2) just so he can roll over in his grave).

got checkout, for example, can limit itself to a subdirectory of the repository.

1. https://gameoftrees.org/got.1.html

2. "I credit CVS in a very very negative way. Because I, in many ways, when I designed git, it's "what would Jesus do" except that it's "what would CVS never ever do"-kind of approach to source control management. I've never actually used CVS for the kernel. For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company, and I hate it with a passion.

"When I say I hate CVS with a passion, I have to also say that if there any SVN users (Subversion users) in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was 'CVS done right' or something like that. And if you start with that kind of slogan, there is nowhere you can go. It's like, there is no way to do CVS right."

Undeadly provides more context:

https://undeadly.org/cgi?action=article;sid=20190810123007

Including a link to the lobste.rs with comments from stsp@ (main developer on got):

https://lobste.rs/s/sxpmar/game_trees_version_control_system...

Is this essentially a new CLI front-end to git? I'm excited to see the result.

As a big fan and user of git i'm fairly unhindered by it's CLI design, however i'm quite aware of it's issues through helping many people learning from the outside-in - who's problems are often rooted in misconceptions caused by an exposure to git's porcelain without any understanding of the underlying graph they are manipulating... Perhaps OpenBSD can make a more honest CLI that might eliminate this confusion.

Although others have already answered that got is a BSD implementation, you might want to have a look at Gitless. "A simple version control system built on top of Git".

Basically it just runs git commands, but with a command line interface that is meant to be consistent and more user-friendly.

https://gitless.com/

No, it’s a BSD-licensed reimplementation of part of git (it currently supports local version control operations only)

No, it‘s a completely new implementation. The whole backend and frontend is written from the ground up.

Fair enough, but since it actually uses git repositories as the storage format it uses the most interesting part of git, so my point stands about everything in between the repo and the user.

Looking at the man page, it also seems like you won't be able to share work trees between git and got. If you want to use both to operate on a repository you need a separate checkout for each tool.

Yes it's a new CLI front-end. In fact it's a BSD/ISC licensed reimplementation/reimagination using the git repo structure for file storage. Commands differ a bit and knowing the OpenBSD developers, it will be more consistent and user friendly then git's CLI. Also it's taylored around OpenBSD's development style.

I don't quite understand the aim, or why it overlaps with OpenBSD. This is to provide a different, simplified CLI to git?

In addition to the simplified CLI and the license, there is also the mention of using Unveil/Pledge throughout the code. That seems consistent with OpenBSD and probably is a big part of this. AFAIK, that is also something that would make the code fairly tied to OpenBSD at the moment at least.

I've worked with stsp for a number of years on SVN. He is a thoughtful developer. I am not sure what got him started on this but I hope this comes together for him.

I'm not a developer,

(1) GIT is GPL licensed. OpenBSD does not use GPL code.[1]

(2) The developers saw something about git that they thought they could improve. (usually based on security/code-correctness, see: OpenSSL, OpenSSH, unwind, openrsync, etc..)

[1] https://www.openbsd.org/policy.html

> OpenBSD does not use GPL code

OpenBSD has used a lot of GPLv2 code, until recently their platform compiler was a heavily-patched version of the last GPLv2 version of GCC.

There are git implementations under permissive licenses as well. And it seems like GOT is yet another such implementation.

> a lot of GPLv2 code

"A lot" is quite the exaggeration for "at most 5".

GPLv2 licenced software:

• cvs

• texinfo (for software lacking proper mdoc(7) manuals)

• mkhybrid

• readline

• gcc/gdb/bintuils, supporting libraries libstdc++/libiberty*

The amount of GPL licensed software the resides in OpenBSD base is trivial compared to the entirety of software comprising a complete Unix operating system. Including its own implementation of a wide variety of network protocols, and being the home of OpenSSH, and tmux and many more.

https://www.openbsd.org/innovations.html

* On architectures that have transitioned to a LLVM toolchain, we already have a reference platform (arm64) which doesn't build or install gcc/binutils or supporting libraries, this will happen on other platforms as well, where they're currently installed alongside clang. OpenBSD has already transitioned to clang, lld, libc++/libc++abi on i386/amd64/armv7/octeon.

> cvs

You know, I had forgotten that they failed to bring OpenCVS to bear. Isn't it kinda silly to be concerned about replacing a GPLv2-licensed SCM with another one?

What are you on about?

CVS is GPL. OpenCVS is BSDL.

Git is GPL. Got is BSDL.

I got nothing against GPL, but I am pro diversification (competition = good, monoculture = bad). Furthermore, these projects add more than just different license. Mainly, better security.

PS: Got, trendy name. Got got?

Hey, could you please not break the site guidelines by taking personal shots at other users, being snarky, or posting in the flamewar style? It makes this place worse, regardless of how solid your underlying points are. If you'd review https://news.ycombinator.com/newsguidelines.html and make your substantive points thoughtfully, we'd appreciate it.

Hi Dan, thanks for the heads up. I agree I could have worded the flagged posts more positive. I've attempted to improve this after you posted your warning. Let me know if you still have concerns. Thanks!

Got is an absolutely terrible name. It's like "Go". It doesn't google well, and it's a proper word that will be used in the same sentences as this project.

Funny-because-confusing open source project names stopped being funny in the 90s.

Sure, but the idea seems to be that using git, as is, would mean relying on more GPLv2 software; my point is that it doesn't.

By all means, if OpenCVS or Got were actually brought to a useful state, that'd be great, but there's no great crisis of new GPLv2 reliance in using Git.

I, for one, would welcome a git clone (hah!) built to the core OpenBSD quality standard, but it seems unlikely that anyone cares enough to do that.

In the mean time, justifying not using Git for OpenBSD on the basis of license falls flat, when you realize you're using GNU CVS anyway.

> I, for one, would welcome a git clone (hah!) built to the core OpenBSD quality standard, but it seems unlikely that anyone cares enough to do that.

That would be got(1). Since yesterday version 0.3, 0.4 and then 0.5 was "released". It's still in early development but good enough for a casual user like me to import the OpenBSD src and start using it. Created some commits, branches, performed rebases. Looks great, but still some rough edges. Also tog(1) is great.

Hi, I clearly misunderstood your post. I implied you didn't know the licenses while I did not understand the "to bear" part of your post, at all. Furthermore, I am sorry if I came across as offensive. You make a good point in this post, clarifying your viewpoint. A viewpoint I can relate to.

It's alright, I am used to being misunderstood, so I choose not to be offended and misunderstand the misunderstander's misunderstandings. :- )

You’re correct, but they also have a strong desire to replace these if possible. There was an old effort to replace gcc with the old pcc before they eventually settled on clang.

> usually based on security/code-correctness,

But note that they also tend to consider usability to be part of security and correctness; if the tool is technically correct but nobody can use it without shooting their own foot, then the tool is bad. Hence things like signify - yes gpg or openssl(1) can do what it does, generally, but you'd struggle to use them and be sure that you'd done it right.

See the other comment with a link to lobste.rs, but I'm afraid this entire project exists to reimplement git as a BSD-licensed tool.

My eyes were rolling pretty hard until I remembered that git was basically born out of a license disagreement with BitKeeper. Kudos to the OpenBSD folks (and/or this developer) for sticking to their principles.

I don’t think that’s the goal. I think it’s more about a clear user experience for their developers, who used CVS for a very long time. While CVS is more rigid and limited than git, it has some benefits too. I see this tool, got, as marrying the benefits of both tools.

What are some of those benefits?

Unambiguous workflow, checkouts of only part of the tree, checkouts of specific files that are being worked on, and probably more that I can’t remember now since it’s been 20 years since I used CVS.

the bitkeeper license disagreement impacted how the tool was used. Git's license really only impacts how its developed.

The logo is the best!

Reply on news.ycombinator.com