I guess you didn't start from cvs or svn, because the experience moving to git was otherworldly. If git was your first versioning system than you had to learn some concepts first, which you already internalized when you switched to Mercurial.
1) tfs: shelves are named and can be worked with independently; git: stashes are numbered in a sort of a stack and only the top stash is unpacked and deleted destroying your data, infuriating, also local edits are moved into the stash, not copied.
2) tfs: branches are mapped to different folders and can be worked on simultaneously; git: branches are mapped to single folder and switching branches deletes local edits.
3) tfs: pulling from server merges new text preserving local changes; git: pull and checkout deletes local changes.
4) tfs: can't commit unresolved merge conflicts; git: commits just fine, it's also not obvious if you have merge conflicts to commit or not.
5) tfs: handles concurrent edits as merge conflicts and handles them as they occur; git: you create feature branches and in case of concurrent branches you have merge conflicts when you merge to master, then you have p.4. Feature branches are advertised as a big fat killer feature of git, but I don't quite see the win here, you still have merge conflicts.
6) tfs: all commits in a branch are visible, it's not obvious how to delete them, you can only create rollback commits; git: if something happens to the branch label, the commits are gone.
I don't think your comparison makes sense. Git stash is a way to quickly get to a clean local workspace that can be reversed as you see fit. You use local branches to track independent work.
> tfs: can't commit unresolved merge conflicts; git: commits just fine
Again, this doesn't make sense. In git, users determine whether a conflict is resolved or not. If you commit a changeset originating from a merge conflict, you have to explicitly state that the conflict was resolved and your changes are good.
> Feature branches are advertised as a big fat killer feature of git, but I don't quite see the win here, you still have merge conflicts.
Honestly I didn't understood what point you tried to make. Merge conflicts happen because multiple sources of change touch the same document region in a way that can't be resolved automatically, thus needing human intervention. To the best of my knowledge, there is no cvs in the world that eliminates merge conflicts.
Regarding Git's support for feature branches, the fact that you don't understand the big win Git brought to the world with it's branching model is already a testament to how groundbreaking Git was at the time, and how everyone around was quick to roll out Git clones that follow the same approach. To see what I mean, spend a day working with a SVN repository trying to do work involving feature branches.
> git: if something happens to the branch label, the commits are gone.
Aren't you actually saying that if you delete a branch then the branch is deleted?
Local branches store immutable state, but shelves can be unpacked anywhere (like a stash), thus local changes carry over, but git deletes them on every occasion.
I want my VCS to be quiet, out of sight and do as it's told, because my main focus should be programming, not how to tame a tool that's supposed to save text. The fact that you have to "learn git", and that there are so many StackOverflow git question on how to do (what should be) trivial operations is probably a hint that things aren't great in the usability department.
For hg, I just read an introductory guide (I think it was Joel Spolski's one) and that was enough. I used to be able to do a more in-depth comparison and criticism but nowadays I use git and try not to think about it too much.
I see this claim often, but it never is accompanied by evidence or any concrete example.
I've been using Git for years and I never noticed any semblance of unintuitiveness or bad defaults. Everything in the happy path is straight-forward, and all obscure things are a quick googling away.
Do you actually have any concrete example to back your claims? What's the absolute best example you can come up with of said unintuitiveness and unfriendliness?
Just compare the man pages! "git help clone" vs "hg help clone".
A random (trivial) example off the top of my head. When working with branches:
> git pull
> git switch another-branch
Your branch is behind 'origin/another-branch' by 2 commits, and can be fast-forwarded. (use "git pull" to update your local branch)
... why? I literally just pulled, why are you asking me to pull again? 99% of the people on the planet literally want the last version of that branch (provided there's no local changes leading to a conflict).
Compare with hg:
> hg pull
> hg update another-branch
Done.
I haven't worked with hg in a long time so I can't really provide an "absolute best example". All I can say is that, from memory, hg always got out of the way, and when I wanted to do something out of the ordinary I could either guess how to do it or it was easy to figure out from the manual.
With git, almost nothing's easy. It can become easy if you invest a lot of time in understanding how it works internally (which explains some of its CLI choices). But that to me is a sign of a bad tool. "all obscure things are a quick googling away" - why expose the user to obscure things to begin with?
We've had dozens of discussions about this here on HN – with lots of evidence and concrete examples.
https://www.google.com/search?q=git+user+experience+site%3An...
The entire CLI is badly designed, with highly non-orthogonal commands interacting in unexpected ways. Recent versions of git has started introducing commands with a more top-down design (e.g. git switch), but that's a very novel development
Git also diverged significantly from the SVN command line, but instead of following the tasteful Darcs path of making commands clearer and cleaner it commonly:
- reused the same terms for different operations, usually less intuitive ones (e.g. the absolutely awful "git revert")
- removed clear commands to confusingly tack them onto others (e.g. "git add" to resolve commits)\
On that front, mercurial extended the existing commands-set much more cleanly and clearly.
Mercurial's CLI felt like an improved extension of SVN's, Darcs felt like a drastically different take with plenty for it, Git's felt like one of those ransom letters cut out of newspapers, full of jangly bits which make little sense, and concepts which worked fine altered for no perceivable reason.
Isn't git switch syntactic sugar for git checkout? What's wrong with checking out a branch?
The fact, e.g., that it's a completely different operation than checking out a single file or folder? (One changes HEAD, one doesn't. One warns about overriding local changes, one doesn't, etc.)
Users that started with Git are more likely to internalize Git's concepts as "the natural way to do version control", and more likely to find Mercurial counterintuitive.
But where mercurial shines with a clean, consistent and simple UX, git is a mess where storage-layer abstractions leak to the user and where single commands serve multiple unrelated purposes.
To give you a practical example, any command that takes commit(s) as argument (for checking-out, logging, rebasing, …) would be passed a `revset` in mercurial-land. Revsets are a simple DSL to address commits (by hash, lineage, topology, distance, …), which makes new commands easy to learn, and renders one third of `git help log` inadequate. Most commands that output something use templates as argument, which renders another half of `git help log` laughable.
There is nothing "natural" about the git UX, you've got to accept that it grew organically with no attention to details.
All this to say, I love git, and as a versioning system, it seems obvious to me that we can do better than git for 90% of workflows. Just yesterday I was surprised by how `git push --tags` worked and had to read the man page for `git-push` to see I wanted `git push --follow-tags`. Just reading this forum today I see that I alternately probably(?) could have figured out what I wanted with `git help push` which I didn’t even really realize was a thing.
But do I want to use an easier versioning system? I’m not sure. git has a kind of forcing function for a growth mindset. I value it for its creative expressivity.
Edit for sibling comment: Stockholm Syndrome, quite possibly. But as the “victim,” I still love git!
That's not to downplay git qualities, but as a social experiment in soft peer-pressure and group-thinking, I think it has value (though that's beyond my field of expertise).
I came to mercurial when, after shooting myself in the foot with git for the N-th time and going on a rant about it, someone on IRC told me to give mercurial a shot and move on with my life. I confess that TortoiseHG helped me translate my git habits into the equivalent hg commands, and the kind of history exploration that I was doing then set me up to speed with the revset way.
Then, what I found formidable was that all the knowledge about git intricacies that I had accrued and internalized with pride over the years became absolute no-brainers and irrelevant in the hg world: I remember a famous stackoverflow thread in 10 steps for merging two unrelated repos (including arcane git commands, shelling-out to sed, and non-transactional storage-level ops that would warrant a backup, as was the norm back then). How do you get history from a repo in hg? `hg pull`. How would you go about getting history from a repo (unrelated) in hg? `hg pull` as well. And thinking about it, would have git been nicely designed, it wouldn't have had to care about the difference and even less so had to expose it to the user.
Mercurial, although not perfect, really opened my eyes on what good UX design should look like.
I'm not saying mercurial is better, but there's a reason I have to remind people that this[1] is satire - the real manuals are so convoluted that they seem like parodies of themselves.
[1] https://git-man-page-generator.lokaltog.net/#c2NyZWVuJCRnYXJ...
I feel like the Mercurial fanbase is just another loud fanbase. I did start with CVS and SVN and git was absolutely fantastic when I started using it. On the other hand I could never get the hang of Mercurial. From MY PERSONAL perspective it has a terrible UX(which is the exact opposite experience of the loud hg fan git critics on HN). I absolutely cannot relate to the people who say that Mercurial has the better UX, but I don't remember myself constantly bashing mercurial either like the other side does. From my perspective `git add -p` is an important essential functionality that hg does not provide. I believe there was some sort of plugin but it was no where near as polished.
Yes, there are a handful of nice features in mercurial, but none which are actually necessarily needed inside of the git core.
I do faintly remember that my biggest problem with git was understanding that a commit doesn't push automatically. But then again that's just a difference between a DVCS and whatever was there before.
Mercurial has an interactive commit mode (hg ci -i) with a slick TUI for navigating and selecting chunks to commit.