Mercurial has comparable features (though maybe not obvious to someone accustomed to git) without the usability problems that still plague git nearly two decades later. Hg's interface was made with humans in mind. Git's was made to cut you.
(And it has cut so very many people that it's consistently among the most popular topics in Q&A forums, and has even inspired comics.)
Thankfully, git's early cross-platform shortcomings were eventually fixed, so that's at least some progress. I hope its UI and docs eventually get some love, too.
The interface is the best I know of, a lot like pre-Microsoft github. Especially important to me is that It doesn't intercept my browser's built-in shortcuts like github now does, or require javascript or bury things under submenus like gitlab does.
The promise of federation is appealing, too.
I plan to use it for new public projects, and might even move my old ones over.
Imagine giving someone your phone number, and having them say you have to get a different one because they don't like some of the digits in it.
I have seen this nonsense more times than I care to remember. Please don't build systems this way.
If you're trying to do bot detection or the like, use a different approach. Blacklisting email addresses based on domain or any other pattern does a poor job of it and creates an awful user experience.
(And if it prevents people from using spam-fighting tools like forwarding services, then it's directly user-hostile, and makes the world a worse place.)
Checking MX in your application means you needlessly fail on transient outages, like when a DNS server is rebooting or a net link hiccups. When it happens, the error flag your app puts on the user's email address is likely to confuse or frustrate them, will definitely waste their time, and may drive them away and/or generate support calls.
Also, MX records are not required. Edit to clarify: So checking MX in your application means you fail 100% of the time on some perfectly valid email domains. Good luck to the users and support staff who have to troubleshoot that, because there's nothing wrong with the email address or domain; the problem is your application doing something it should not.
Better to just hand the verification message off to your mail server, which knows how to handle these things. You can flag the address if your outgoing mail server refuses to accept it.
I might give Backpack Battles a try. It doesn't look like my usual style, but I heard there's some good strategy under the surface, and I like that it's made with Godot.
fixed [S_API FAIL] SteamAPI_Init() failed; no appID found. from being reported when running non-steam games
non-steam games will now run using wine inside proton rather than calling steam.exe with wine then the game inside steam -- this goes alongside the API failure fix
controller axis patch added from 8-27 has been removed as it is now properly upstreamed
can now call the winetricks gui using util.protontricks('gui')
winetricks now performs an internet check before attempting any downloads
fixed long standing issue with protontricks not being able to install dotnet4* using anything newer than proton 5. works now and no longer requires proton 5.
fixed dll overwrites in winetricks, no longer need to maintain a massive list of specific overwriteable dlls in proton
protonfixes added for Catherine Classic -- videos now fully working
protonfixes added for Ys Origin -- videos now fully working
protonfixes for Age of Wonders -- videos now fully working
protonfixes added for Model 2 emulator
protonfixes added for Alien Breed: Impact
protonfixes added for Alien Breed 2: Assault
protonfixes added for Alien Breed 3: Descent
protonfixes added for Black Desert Online NOSTEAM=1 option. Launch game like NOSTEAM=1 %command% to launch non-steam standalone version.
I have good news for you:
https://www.polygon.com/24074441/gigantic-game-relaunch-rampage-edition-steam-release-date