I'm more of a mercurial guy (since 2009) and I honestly never understood the success of git with its total nonsense of options, UX and documentation. Each command does too much thing and has different behavior. Type git diff -x and git switch -x in a non-git repository and check the output...
It is an OpenBSD culture reference though [1], not some sort of attempt at an insult. I would personally be sad to see it go as it does make me smile when a program is not too "corporate" and reminds me every time I see it that I have the power to pull through on my own (most of the time) if I just put my mind to it.
Jj is arguably also in this vein, albeit much more heavyweight.
By virtue of almost universal adoption, git as an on-disk and interchange format give us an opportunity to treat is simply as an API and experiment with new UX on top. Would love to see more of this kind of thing.
Mercurial is slower than git. It has a few minor features that git does not have, but git has major features that Mercurial doesn't have. Git also supports interoperability with SVN out of the box, but Mercurial only has unofficial (and probably broken) plugins to do that. I used Mercurial for a few years but there is absolutely zero reason for me to go back. I would miss several lesser-known git features that I have come to rely on.
Related. Others?
Game of Trees - https://news.ycombinator.com/item?id=43438659 - March 2025 (6 comments)
OpenBSD – Game of Trees 0.102 released - https://news.ycombinator.com/item?id=41250257 - Aug 2024 (2 comments)
OpenBSD – Game of Trees 0.99 released - https://news.ycombinator.com/item?id=40271467 - May 2024 (1 comment)
Comparison of Game of Trees to other version control systems - https://news.ycombinator.com/item?id=36800541 - July 2023 (1 comment)
OpenBSD: Game of Trees 0.90 Released - https://news.ycombinator.com/item?id=36456887 - June 2023 (15 comments)
Game of Trees (Got): A Version Control System for OpenBSD - https://news.ycombinator.com/item?id=20665787 - Aug 2019 (2 comments)
Game of Trees: A Version Control System for OpenBSD - https://news.ycombinator.com/item?id=20657650 - Aug 2019 (40 comments)
Seems neat, but very expensive
I'm more of a mercurial guy (since 2009) and I honestly never understood the success of git with its total nonsense of options, UX and documentation. Each command does too much thing and has different behavior. Type git diff -x and git switch -x in a non-git repository and check the output...
I love OpenBSD and I'm really interested in got for several years. I just hope that this https://framagit.org/stsp/got/-/blob/main/got/got.c?ref_type... gets removed at some point.
> I love OpenBSD and I'm really interested in got for several years. I just hope that this https://framagit.org/stsp/got/-/blob/main/got/got.c?ref_type... gets removed at some point.
It is an OpenBSD culture reference though [1], not some sort of attempt at an insult. I would personally be sad to see it go as it does make me smile when a program is not too "corporate" and reminds me every time I see it that I have the power to pull through on my own (most of the time) if I just put my mind to it.
[1]: https://www.openbsd.org/lyrics.html#51b
9front has quite a nice implementation. It provides a unique, parsimonious UI. It's also very little code!
https://git.9front.org/plan9front/plan9front/427e868e2be75f2...
Jj is arguably also in this vein, albeit much more heavyweight.
By virtue of almost universal adoption, git as an on-disk and interchange format give us an opportunity to treat is simply as an API and experiment with new UX on top. Would love to see more of this kind of thing.
That message should go. Also don't know if it's amalgamation or just because, but look ma, a single, 300k+, 14-kloc+ C source.
Mercurial is slower than git. It has a few minor features that git does not have, but git has major features that Mercurial doesn't have. Git also supports interoperability with SVN out of the box, but Mercurial only has unofficial (and probably broken) plugins to do that. I used Mercurial for a few years but there is absolutely zero reason for me to go back. I would miss several lesser-known git features that I have come to rely on.