Seems driven primarily by wanting a BSD licensed option. The OpenBSD folks are very talented but are also very ideologically driven. I'm not sure this will get a lot of attention but it is nice seeing another option.
Yes and no, my experience with it is that it is trying to be a minimal Git format-compatible tool that conforms with the coding style and practices of the OpenBSD community, along with their style of development: patches onto mailing lists. It is likely the hope of its developers that it would be included into OpenBSD base at some point. So, true, the license is a part of it, but one part of many.
The goals page also implies it is intended to adapt to more OpenBSD filesystem permissions model things, which aren't as important in Linux or cross-platform development (git's intended environments).
I was reading more into this specific in the project goals:
> Consistently use pledge(2) and unveil(2) across the code base.
Both link to man pages that seem rather OpenBSD-specific to me. Seems an interesting requirement/goal, but I'm afraid I don't know enough OpenBSD-specifics to know much more about why this is a goal or what the project gains from having it as a goal even if I can appreciate it as a goal that certainly seems unlikely to upstream into git itself.
(ETA: Which yeah, it does seem like the Comparisons page includes some of that reasoning, but not well enough I caught on first skim and I'm still not sure I understand it on second reading, but interesting.)
i don't know OpenBSD either, but i am guessing they are similar to linux capabilities where a process can reject certain permissions, or where you can remove permissions before starting the process. so the goal is pretty clear. make those apps safer to reduce the risk of exploits. this goal goes through all apps written by OpenBSD devs. for apps that deal with foreign user data that is an important feature.
Seems driven primarily by wanting a BSD licensed option. The OpenBSD folks are very talented but are also very ideologically driven. I'm not sure this will get a lot of attention but it is nice seeing another option.
Yes and no, my experience with it is that it is trying to be a minimal Git format-compatible tool that conforms with the coding style and practices of the OpenBSD community, along with their style of development: patches onto mailing lists. It is likely the hope of its developers that it would be included into OpenBSD base at some point. So, true, the license is a part of it, but one part of many.
There is also this:
https://gothub.org
The goals page also implies it is intended to adapt to more OpenBSD filesystem permissions model things, which aren't as important in Linux or cross-platform development (git's intended environments).
i assume you are talking about the things mentioned here: https://www.gameoftrees.org/comparison.html
more applications making use of linux capabilities to restrict access would be nice though.
I was reading more into this specific in the project goals:
> Consistently use pledge(2) and unveil(2) across the code base.
Both link to man pages that seem rather OpenBSD-specific to me. Seems an interesting requirement/goal, but I'm afraid I don't know enough OpenBSD-specifics to know much more about why this is a goal or what the project gains from having it as a goal even if I can appreciate it as a goal that certainly seems unlikely to upstream into git itself.
(ETA: Which yeah, it does seem like the Comparisons page includes some of that reasoning, but not well enough I caught on first skim and I'm still not sure I understand it on second reading, but interesting.)
i don't know OpenBSD either, but i am guessing they are similar to linux capabilities where a process can reject certain permissions, or where you can remove permissions before starting the process. so the goal is pretty clear. make those apps safer to reduce the risk of exploits. this goal goes through all apps written by OpenBSD devs. for apps that deal with foreign user data that is an important feature.
> along with their style of development: patches onto mailing lists
I mean that's also Git's style of development.
The web site is seven years old, and the project nine and a half years. So this isn’t anything new.
Sounds cool.
What should we call the magit equivalent for got? Magot? Maggot?
if you only got git then you should git got. ;-) (works best with an australian or new zealand accent)
"Another one? Why not ...?" - https://www.gameoftrees.org/goals.html
If you are wondering why Got even exists, you can just ignore it.
https://www.gameoftrees.org/faq.html