Sourcehut (sr.ht) has Mercurial support in their forge (in addition to Git). Was one of the main reasons for me moving projects over there in the first place, but I really enjoy the simplicity of the UI and general minimalist approach. I don't know whether it does CI/CD pipelines or anything, since I've little call for any of that, so ymmv.

It does do CI/CD, for what it’s worth[1,2]

[1] https://builds.sr.ht/~sircmpwn/builds.sr.ht

[2] https://man.sr.ht/builds.sr.ht/

Agreed, mercurial is a joy to use.

It's very annoying that git became more popular, it's such a disaster from the usability point of view.

> It's very annoying that git became more popular, it's such a disaster from the usability point of view.

I don't understand this sort of comment at all. What's so hard about git?

You clone a repository, you checkout a branch, you pull changes to that branch from the remote server, you commit a change to your local repository, you push those changes to a remote server.

What's so hard to get?

It's even more absurd when people try to claim that mercurial is so clear while criticising git for being unintelligible, when mercurial follows the exact same patterns but had to confuse people by leaving basic features like stashing as an afterthought to be implemented with ad-hoc extensions.

Because of the other 8 million things you can do with git, especially when things go wrong and you're trying to undo them and the commands are very cryptic.

Have zero problems with it, have you tried to RTFM?

Yes, I read the manual every time I need to do anything but push and pull. Because I have to. ;-)

> Yes, I read the manual every time I need to do anything but push and pull. Because I have to. ;-)

Can you provide a single example of what you think is the absolute worst userflow that git provides for a basic everyday feature? I'd like to understand why some people repeatedly make a mountain out of a molehill regarding git's user experience.

It's no molehill, and they are well known. Just go to stack overflow and see git questions with ~20,000 votes each! Not just that but note how many answers there are for each one, how much story-telling is involved, and how advice changed over the years:

https://stackoverflow.com/questions/tagged/git?tab=Votes

This is not the mark of good interface design. The ones I look up every single time off the top of my head are:

    # undo commit 
    git reset --soft HEAD~1

    # unstage
    # was git reset HEAD --
    git restore --staged

I created aliases for most of the common ones, like deleting old branches:

    # https://stackoverflow.com/questions/2003505
    nuke = "!f() { git branch -D $1 && git push --delete origin $1; };f"

Others like checkout/switch have been fixed, but I still use my aliases from ten years ago so haven't really updated.

A few times I tried the rebase workflow geeks are always pushing. They are never around when disaster strikes, so I don't bother any more. At least merge+squash works every time.

Notice that commands like git status tell you what commands to run to fix issues; the typical user would never guess. Hg wasn't perfect but it had a lot fewer of these issues.

I still save changes to a file if I switch/merge while having a bigger changeset as I use PHPStorm and it caused me a semi heart attack at least 3 times with the “unstashing failed“ error (that also removed it from the stash at the same time)

The best thing about Jetbrains IDEs is local file history - so you dont have to rely on git - you can still see file history and directory history to restore commits and deleted files. Saved me many times.

VS Code added that feature too recently, very nice addition https://code.visualstudio.com/updates/v1_44#_timeline-view

Thanks I didn't even know that was there, this will help me. It looks like its files only, not directories which is important to get accidentally deleted files.

Local history is great and I dont understand why it's separate from the undo stack, which is limited in size (by default?). Actually, both could be integrated with SCM as fine grained autocommits + eventual squash on manual checkpoint / push.

The other option here is to do a "WIP" (work in progress) commit. Which you can undo (moving the files back into the staging area) with `git reset HEAD^` once you switch back to the branch. Annoying that this is necessary - it would be great if git stash was as robust - but this won't lose your work.

You can also use `git stash apply` (which doesn't pop the stash), followed by maybe merging, and finally a `git stash drop`.

You can also use the git reflog to get the recently dropped stash commit's sha, and then check out the files that you miss.

If a change has ever been committed or stashed (which is basically also committing, just not on a branch), it can always be recovered, at least until garbage collection is run - check out the reflog. Of course, if it hasn't been, then you can lose it.

Yeah, working out which stash contains your work can be quite tricky though! As they are not named by default.

You can add a tag to the change you want to keep. Whatever you do, you can recover it (git reset --hard tag). Once you are done, remove the tag. Otherwise, there is the reflog, like mentioned in a sister comment.

standard branches can serve this purpose