I use git daily and it works, but man did it take a long time until I got confident enough to not make a backup.tar.gz before some more complex operation. And I still hate the fact that there are N additional obscure ways to do each operation.
Mercurial otoh was a joy to use, never surprised me - it just worked. I think github is the only reason git won. Ah well, water under the bridge...
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'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.
> 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:
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.
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.
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.
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.
> Although Mercurial was not selected to manage the Linux kernel sources, it has been adopted by several organizations, including Facebook, the W3C, and Mozilla. Facebook is using the Rust programming language to write Mononoke, a Mercurial server specifically designed to support large multi-project repositories.
Mercurial @ Google:
> Speaking of Google, their Mercurial rollout on the massive Google monorepo continues. Apparently their users are very pleased with Mercurial - so much so that they initially thought their user sentiment numbers were wrong because they were so high! Google's contribution approach with Mercurial is to upstream as many of their modifications and custom extensions as possible: they seem to want to run a vanilla Mercurial out-of-the-box as possible. Their feature contributions so far have been very well received upstream and they've been contributing a number of performance improvements as well. Their contributions should translate to a better Mercurial experience for all.
When I first got into distributed source control I found Mercurial much easier to use. Even though Git has "won," threads like this are a good reminder that there are git bridges for Mercurial that allow you to run Hg locally and then push/pull/branch/etc with a Git remote repo. I need to look into that again.
I've successfully used hg-git on something as large as Waterfox (slight irony there because Waterfox is a Firefox fork, and Firefox's canonical repository is a Mercurial repository, though they also maintain a Git mirror).
The import of something that large unfortunately took a few hours, and it's a bit annoying that under the hood hg-git needs to store both the native Git repository as well as a copy converted to a Mercurial repository, but other than that it works quite fine in day-to-day usage.
And with smaller repo than something like Firefox's the above disadvantages are of course less to hardly noticeable.
I'm using hg-git... was fine until i started working with other humans. my changeset hashes don't match github and git branches map to hg bookmarks which i don't like.
The way some histories tell it, Git didn't win because it was better than Mercurial but because GitHub arrived on the scene and exploded in popularity. Had GitHub been HgHub it's possible that we would be programming in a Mercurial dominated world with Git having been "the other" that fell by the wayside.
Last time I had to use Hg on a client project, disposable topic branches didn't seem to be something really supported. Broke our usual workflow and made a small mess for the client. Is this still the case?
> "rebase -i" is called histedit. It works pretty much the same.
Is there a reflog, though? When I mess up a git rebase, I have confidence I can always undo the rebase and try again.
When I used Mercurial, admittedly over five years ago, there wasn't a reflog. Sure, you'd get some .bak files when editing the history, but that's nowhere near as safe.
No reflog, but there is the obslog, which stores obsolescence history of individual revisions. Better yet, the obslog is distributed during pull / push. Because Mercurial knows precisely which commit is replaced by which commit, it can automatically resolve a lot of conflicts that result from history editing.
Have a branch-a that depends on branch-b that depends on branch-c that upstream just rebased and squashed some of its commits? More often than not `hg pull && hg evolve` is all you need to do to synchronise everything. This makes stacked PRs much easier to manage.
Unless you explicitly set config otherwise, any time you rebase / strip / histedit, a copy of the original commit(s) gets saved and can be restored with a single command.
Am I alone in liking svn? Like, not necessarily "more" than hg/git but not "less" either.
I get everything Joel says in that first page svn rant, but, part of me was like "well why did you choose to use it that way then?".
Even the whole "hg/git are decentralised, svn is not" mantra bothers me. So friggin create a personal svn repo and merge back when ready already. I've used a decentralised svn workflow more times than I can count now. It's really not that hard.
> Even the whole "hg/git are decentralised, svn is not" mantra bothers me. So friggin create a personal svn repo and merge back when ready already. I've used a decentralised svn workflow more times than I can count now. It's really not that hard.
The point is that it took work for you to set that up with SVN, which most people don't do. Git gives it to you for free.
It is true that svn has improved over the years since dvcs became mainstream. New workflows developed as well. Unfortunately no one wants to use anything but git+hub any longer. Networks effects sucked all the air out of the room. gitlab is decent I have to say however.
One thing I miss about Mercurial was only having to type enough of a subcommand to be unambiguous. `hg st` is much shorter than `git status`. I wish all CLI tools worked that way.
It's built in to the Mercurial CLI, whereas tab autocomplete is an additional feature to the user's shell. Thus, by default, every user will have access to the Mercurial shortnames, while only users with autocomplete enabled in their shell (or with autocomplete available for their shell) will have the autocomplete available.
Also, autocomplete is still an additional keypress...
I used hg for years at BigCo, and it’s good, but damn did I miss the git index. Which is kind of amusing given that the git index took a bit of getting used to.
You can use `hg commit --interactive` to use the the commit itself as the staging area. And I'd argue that's a better model because:
- It limits the amount of time changes are stored in an intermediate state, making it much less likely to interfere with other operations, like pulling and switching branches.
- You can use the same commands (and mental model) to manage the "staging area" and other commits.
- The history of staging and unstaging becomes actual history and can be recovered and shared.
The index is an anti-feature in my opinion. People commit in chunks with no guarantees that these commits that are valid all together are valid individually.
The transition to Eden has been... weird. Like, I'm sure it's actually meaningfully better in certain metrics but yeah the fact that rebasing from one local commit to another local commit requires a bunch of network I/O is non-obvious and slow... Checkouts feel so much slower, too.
Further slowed by HHVM deciding to crash itself after a "large" rebase to download type checker saved state remotely because that'll somehow be faster than rebuilding it locally is...
I was a very long time user of mercurial since it's early inceptions. It helped me really visualize the work as a set of patches. It has history rewrite feature on local, but it doesn't allow to force push the rewritten history/branch. We had to do lots of work arounds, processes, etc to cover for the lack of.
After switching to git, it felt complete. Yes, git UI is horrible and has the drawbacks of the snapshot model. But it is perfect for a team setting. This is why GitHub won and in turn git.
Does anybody else remember Bazaar? bzr was the first DVC I used, right before switching to hg. I liked hg more than git and still use it on one project but git just took over. I think git's adoption was not only pushed by GitHub but also by being faster. HgHub would probably still not have won against GitHub due to its early popularity in the Ruby on Rails community and since self-hosting Mercurial over https was much easier compared to git.
I remember using an experimental feature of bzr to branch from subversion (that my employer then used), make local commits using bzr and merge back to svn. That was so cool.
Subversion is still my favourite VCS for collaborating on non-source data.
I.e. cases where you typically exchange documents over email/dropbox and use extension-based versioning (e.g. report.v22.final.docx). Subversion keeps all data in one repository nice and tidy. Works well with binary files. Allows easy subtree checkouts. Plus, explicit commits make it easier to track progress without having to dig in your mailbox.
Hell, I had one client still using CVS a few years ago, and they couldn't see any reason why I was suggesting they might want to change.
Granted their business was manufacturing electronics for passenger aircraft, so any change in their tooling might trigger an expensive, multi-year recertification across their product line, so maybe they were right...
A LOT of companies still do. Every bigger company i've been to here in germany has used it somewhere. Some tried to slowly move to git, most didn't, because svn just works and old people don't want to change
I'm sure plenty teams at engineering companies do. These people mostly are not SW developers by training (i.e. they write SW incidentally), and SVN is an order of magnitude easier to use than git.
> Git: 50 mins of googling to know what the next 5 commands to type.
That's quite the odd statement, as all it takes is a 5min tutorial to get up and running on 95% you ever need to do with git on a weekly basis, and 100% of what you do at an everyday basis.
> Hg: 5 mins of googling to know what the next 50 commands to type.
This is not the brag you think it is. If you need to know 50 commands to do daily work with a revision control service, that service is appallingly broken by design.
Also, you forgot to mention the need to install ad-hoc extensions in mercurial to have access to basic stuff.
It's odd only if you are new to DVCS. In the early days of git and hg, git commands were lots of plumbing and very little porcelain. At the time, most people switching from svn to a DVCS almost universally found hg a basically effortless switch. The success of git is due to 1) Linus fandom/cargo cult. 2) Ruby on Rails groupthink, and 3) Github.
> If you need to know 50 commands to do daily work with a revision control service, that service is appallingly broken by design.
Consider just the simple task of "forget about the last commit I made." Mercurial has like five different ways to do this (hg rollback, hg uncommit, hg strip, hg prune, hg histedit), which work in three totally different ways under the hood (obsolescence markers, backup bundles, or just YOLOing it in the case of Rollback), and which may change their behavior depending on whether you're using `evolve`. As a novice, it's not clear which you should be using (hint: use the evolve extension) or how to recover from mistakes.
Git also has several ways to do it, but all operating on the same principles. Whether you `git reset` or `git branch -m`, or `echo $(git rev-parse $BRANCH~) > .git/refs/heads/$BRANCH`, you're just moving pointers around, and the reflog makes recovery simple.
Consider just the simple task of "forget about the last commit I made." Mercurial has like five different ways to do this (hg rollback, hg uncommit, hg strip, hg prune, hg histedit),
Wow 5 commands, none of which have a confusing - or -- flag, or are an overload of another command? That's really impressive.
I've been using git non-stop for 7 years at this point. I have no idea how to "forget about the last commit I made." off the top of my head. I'm sure one day soon I'll need to do it, will look it up, and then forget it immediately because gits cli makes no sense.
The amusing thing about your comment? I could immediately think of at least one way to do it in Mercurial, whereas with git I didn't - I would have to Google it.
And in the last 3 years I used Git a lot more than Mercurial.
Again, I've had the opposite experience. I've used nothing but Mercurial at work for the last 2.5 years, and yet how to do this in git was obvious (and `git rebase -i HEAD~` gives a fourth way).
But even using Mercurial day-to-day, I had to look up whether `hg strip` or `hg uncommit` has `evolve` integration (no and yes, respectively), and I'm not sure I could fix botched history edits.
Off topic, but the drop-off in searches during pandemic seems to indicate how little work people actually did whilst working from home...it's quite surprising.
Mercurial otoh was a joy to use, never surprised me - it just worked. I think github is the only reason git won. Ah well, water under the bridge...
P.S.: hginit rules.