I'm curious: are you specifically talking about the GitHub-style fetish for "a fork and feature branch for everything, followed by a merge"? I've been on a tear lately against GitHub after having another go at using it (it's where the collaborators are) and finding that it's still as terrible as it's ever been.
Have you used Git extensively outside of GitHub or done much with Mercurial? Patch-based/commit-only workflows are the right solution to, I dunno, probably 75% of fixes and don't get in the way like the aforementioned approach, which tends to be misapplied (read: used 100% of the time because GitHub demands it).
Commit-only workflows are very light on ritual, since it's got about the same overhead as leaving a two-line comment. Mercurial makes it even lighter, because you don't have to futz around with the index like you do in Git (so long as you're only changing an existing file and haven't introduced a new one).
I do use it, but that still qualifies as having to "futz[...] around with the index":
> -a, --all
> Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
But this wasn't supposed to be a Git vs Mercurial post. It was supposed to be a GitHub vs sanity one, where Git-based solutions exist in the latter, too, which is why I mentioned use of Git outside of GitHub.
Have you used Git extensively outside of GitHub or done much with Mercurial? Patch-based/commit-only workflows are the right solution to, I dunno, probably 75% of fixes and don't get in the way like the aforementioned approach, which tends to be misapplied (read: used 100% of the time because GitHub demands it).
Commit-only workflows are very light on ritual, since it's got about the same overhead as leaving a two-line comment. Mercurial makes it even lighter, because you don't have to futz around with the index like you do in Git (so long as you're only changing an existing file and haven't introduced a new one).