Hi, I am the Game of Trees project founder and main author of the code.
If there is anyone here who would be interested in seeing this project
advance faster and has funding available, please talk to me.
I am a freelancer with an EU VAT ID.
Progress since the beginning in 2017 has been steady but slower than I would like.
I have occasionally applied to various open source funds (prototype fund,
NGI zero, and the like) but was never lucky enough to get funds allocated
(which is fair: many other great projects are being funded instead, so I am
not bitter about this).
And I don't want to bother the OpenBSD Foundation since they are already partly
funding unrelated work I am doing in the OpenBSD wifi drivers and 802.11 stack.
I also believe that the ability to run this alternative Git client on any nix,
and the alternative Git server on OpenBSD (though there are plans to port the
server to any nix as well) can be useful for many communities and organizations beyond OpenBSD.
Some things I would like to work on in particular are:
- SHA256 object ID support, enabled by default, with repositories running
either SHA256 or SHA1, without the ability to mix different hashes in the same
repository. The server could offer a read-only repositories converted
to SHA1 for legacy clients which do not support SHA256. Git itself does
already support SHA256 so this won't break compatibility with regular Git clients. Though it might not be possible (yet?) to push SHA256 repositories to many hosting sites but that is not Git's fault.
- Server-side "trivial-rebasing" of changes, such that clients could push
changes to servers without having to fetch first, provided pushed changes
can be merged tree-wise, ie. without any file content clashes or unclean
additions/deletions of files.
- Performance improvements; Got currently spanws one privsep child process per pack
file on disk, cycling children in and out as needed when there are too many
pack files. This can cause a lot of forking during random access across the
entire history, which occurs when computing deltas while packing.
Small pack files should be stored in memory instead, and each child process
should be able to handle multiple packs to reduce the amount of forking.
You can skim the man pages to see all the work that has already
been done: https://gameoftrees.org/manual.html
And of course you can read the source code; see the web site for details.
As with OpenBSD, there has been discussion for ages about moving NetBSD from CVS to something else. However, nobody has slimmed down any of the considered VCS to be small enough to add to NetBSD's base. I think Got is worth considering. I'm looking forward to reading more and trying it out myself. Thanks!
absolutely not. openbsd decide to reinvent the wheel for their own bubble let them pay. you say server is openbsd only too in post. maybe not you but other openbsd devs dont give back either (despite project docs and policy) and even change the openbsd docs to no longer say contributor should give back to upstream (this is documented). why should there be trust this will care about others and the money is for this specific development?
tldr prove its not another openbsd NIH project and people outside openbsd care or f off
OpenBSD regularly produces "NIH" projects that the rest of the industry adopts, takes from, and (usually) never gives back. Even where not commercially successful, projects like GoT or LibreSSL ensure we're not living in a monoculture.
If you don't have anything kind to say to them (even "thanks" would be more than most people can be bothered with), then better don't say anything.
For those that are curious about the motivations and implementation, I recommend Stefan Sperling’s EuroBSDCon 2019 talk [1] and its slides [2]. You will find examples of the workflow at around 12:30 or from slide 23.
In short, it builds on top of the same protocol and format as Git and is thus compatible. But aims to be minimal and primarily serve the mindset and needs of OpenBSD developers. There are however portable releases and as we have seen in the past, OpenBSD software tends to find its way far outside OpenBSD itself: ssh(1), tmux(1), etc.
Git is not insufficient. For various reasons, Git is not a good match for what OpenBSD needs. OpenBSD needs an implementation that uses privsep, pledge, unveil, fits the mindset needed for Theo to accept running it on his own infrastructure, doesn't carry more baggage than necessary, and is a joy and easy to work on for OpenBSD developers independently from third parties. So the options were forking Git or writing something else, and I chose to do the latter.
> Got is a new system which relies on prior art and takes what makes Git's design great, leaves out the parts that make Git hard for us to use, and invents new parts for an end result which serves our needs.
Could somebody here expand on this? From a user point of view, what are the bad parts of git left out? What are the invented new parts?
Is there an exausthive comparison list somewhere?
If there is anyone here who would be interested in seeing this project advance faster and has funding available, please talk to me. I am a freelancer with an EU VAT ID.
Progress since the beginning in 2017 has been steady but slower than I would like. I have occasionally applied to various open source funds (prototype fund, NGI zero, and the like) but was never lucky enough to get funds allocated (which is fair: many other great projects are being funded instead, so I am not bitter about this).
And I don't want to bother the OpenBSD Foundation since they are already partly funding unrelated work I am doing in the OpenBSD wifi drivers and 802.11 stack. I also believe that the ability to run this alternative Git client on any nix, and the alternative Git server on OpenBSD (though there are plans to port the server to any nix as well) can be useful for many communities and organizations beyond OpenBSD.
Some things I would like to work on in particular are:
- SHA256 object ID support, enabled by default, with repositories running either SHA256 or SHA1, without the ability to mix different hashes in the same repository. The server could offer a read-only repositories converted to SHA1 for legacy clients which do not support SHA256. Git itself does already support SHA256 so this won't break compatibility with regular Git clients. Though it might not be possible (yet?) to push SHA256 repositories to many hosting sites but that is not Git's fault.
- Server-side "trivial-rebasing" of changes, such that clients could push changes to servers without having to fetch first, provided pushed changes can be merged tree-wise, ie. without any file content clashes or unclean additions/deletions of files.
- Performance improvements; Got currently spanws one privsep child process per pack file on disk, cycling children in and out as needed when there are too many pack files. This can cause a lot of forking during random access across the entire history, which occurs when computing deltas while packing. Small pack files should be stored in memory instead, and each child process should be able to handle multiple packs to reduce the amount of forking.
You can skim the man pages to see all the work that has already been done: https://gameoftrees.org/manual.html And of course you can read the source code; see the web site for details.