5 ms·

I switched from git to Mercurial and was absolutely gobsmacked by how much better it is. The only comparison was switching from a Blackberry to an iPhone - ever

I switched from git to Mercurial and was absolutely gobsmacked by how much better it is. The only comparison was switching from a Blackberry to an iPhone - everything just works exactly the way I want it to. Yes, I read the manual for git, but I never needed to for Mercurial.

baud147258 4y ago
Having used svn, git, mercurial then back to git (with the last two at the same job, the business unit having decided to move from mercurial to a git-based solution) and I've preferred mercurial to git, where it feels like there's more possible foot-guns and its features don't bring enough value to justify the increased complexity when using it .
riquito 4y ago
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.
- jkaptur 4y ago
  No, I started with SVN and (briefly) VSS. I did use git for a while before hg, though, so I guess what you’re saying is possible.
- Tomis02 4y ago
  Due to my workplace I moved from svn to hg (awesome experience) and then from hg to git (terrible experience). That was years ago, and the git experience remains terrible.
  - Varriount 4y ago
    Can you elucidate? What did you find appealing/unappealing?
    - GoblinSlayer 4y ago
      If you're interested, can compare tfs to git. Maybe it's ide integration quality, but FWIW: 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.
      - simplotek 4y ago
        > 1) tfs: shelves are named and can be worked with independently; git: stashes (...) 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?
- eesmith 4y ago
  I learned cvs, sccs, svn, bzr, hg, and git, in that order. I still find git confusing, and stick with Mercurial whenever possible.
- rjzzleep 4y ago
  I think the problem arises from when you switched to hg from those older systems and grew accustomed to it and then were FORCED to switch to git because of work or whatever. 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.
  - cpeterso 4y ago
    > From my perspective `git add -p` is an important essential functionality that hg does not provide. Mercurial has an interactive commit mode (hg ci -i) with a slick TUI for navigating and selecting chunks to commit.
- nemetroid 4y ago
  My experience is the opposite. Most of the staunch Mercurial supporters came from CVS or SVN and found Mercurial to fit better into their preexisting mental model of source control. 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.
  - hoosieree 4y ago
    People don't internalize Git concepts as "natural", they get Stockholm Syndrome. 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/#c2NyZWVuJCRnYXJiYWdlIGNvbGxlY3Rvcg== https://git-man-page-generator.lokaltog.net/#c2NyZWVuJCRnYXJ...
    - LaPingvino 4y ago
      There are two reasons Git is better, and the UI is NOT one of them: speed and repository format. I think Keith Packard wrote about this best: Git is technically under the covers way superior over Hg, it's not even a competition. For usability, I think with Sapling we finally get some real competition and that might be the user interface alternative we need, as well as the monorepo approach it was basically made for, but let's just say that I don't trust people who think Mercurial is technically even close to a good idea.
  - ezst 4y ago
    Not my experience. As it happens, Mercurial and Git are very similar in terms of the "mental model" required to use them: history is just a DAG, and common operations consist of navigating the history and creating/editing/re-organizing commits. 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.
gjulianm 4y ago
What are the changes that Mercurial has? I've read many times that Mercurial is easier but I've never seen the reasons. The times I've used mercurial (mostly to download a repo) it doesn't look that different, and other than the staging area weirdness I don't find git too difficult.
- freeone3000 4y ago
  You know how when using git you have to add tons of flags to every command to make it do what a sane person would actually want? Mercurial just does what you want.
  - LaPingvino 4y ago
    I'm going to be blunt and state that what most people want is not what they actually need. If you use Git for how it was designed, the commands remain generally pretty clean. If you come from an SVN mindset, you are probably not really using Git the way it was designed, and Mercurial fits better. I have used (actually introduced) Mercurial before at a company and considered them basically equivalent enough, only to get stuck in some horrible design choices of early Mercurial (named branches and not having rebase by default). I am happy to see these elements corrected in Sapling, giving me enough confidence that I might actually use Sapling over time...
  - fragmede 4y ago
    Not really, my .hgrc is about as long as my .gitrc, mostly 1 or 2-letter aliases in both. It makes both of them much easier to work with my workflow.

baud147258 4y ago

Having used svn, git, mercurial then back to git (with the last two at the same job, the business unit having decided to move from mercurial to a git-based solution) and I've preferred mercurial to git, where it feels like there's more possible foot-guns and its features don't bring enough value to justify the increased complexity when using it .

riquito 4y ago

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.

jkaptur 4y ago
No, I started with SVN and (briefly) VSS. I did use git for a while before hg, though, so I guess what you’re saying is possible.
Tomis02 4y ago
Due to my workplace I moved from svn to hg (awesome experience) and then from hg to git (terrible experience). That was years ago, and the git experience remains terrible.
- Varriount 4y ago
  Can you elucidate? What did you find appealing/unappealing?
  - GoblinSlayer 4y ago
    If you're interested, can compare tfs to git. Maybe it's ide integration quality, but FWIW: 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.
    - simplotek 4y ago
      > 1) tfs: shelves are named and can be worked with independently; git: stashes (...) 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?
eesmith 4y ago
I learned cvs, sccs, svn, bzr, hg, and git, in that order. I still find git confusing, and stick with Mercurial whenever possible.
rjzzleep 4y ago
I think the problem arises from when you switched to hg from those older systems and grew accustomed to it and then were FORCED to switch to git because of work or whatever. 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.
- cpeterso 4y ago
  > From my perspective `git add -p` is an important essential functionality that hg does not provide. Mercurial has an interactive commit mode (hg ci -i) with a slick TUI for navigating and selecting chunks to commit.
nemetroid 4y ago
My experience is the opposite. Most of the staunch Mercurial supporters came from CVS or SVN and found Mercurial to fit better into their preexisting mental model of source control. 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.
- hoosieree 4y ago
  People don't internalize Git concepts as "natural", they get Stockholm Syndrome. 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/#c2NyZWVuJCRnYXJiYWdlIGNvbGxlY3Rvcg== https://git-man-page-generator.lokaltog.net/#c2NyZWVuJCRnYXJ...
  - LaPingvino 4y ago
    There are two reasons Git is better, and the UI is NOT one of them: speed and repository format. I think Keith Packard wrote about this best: Git is technically under the covers way superior over Hg, it's not even a competition. For usability, I think with Sapling we finally get some real competition and that might be the user interface alternative we need, as well as the monorepo approach it was basically made for, but let's just say that I don't trust people who think Mercurial is technically even close to a good idea.
- ezst 4y ago
  Not my experience. As it happens, Mercurial and Git are very similar in terms of the "mental model" required to use them: history is just a DAG, and common operations consist of navigating the history and creating/editing/re-organizing commits. 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.

gjulianm 4y ago

What are the changes that Mercurial has? I've read many times that Mercurial is easier but I've never seen the reasons. The times I've used mercurial (mostly to download a repo) it doesn't look that different, and other than the staging area weirdness I don't find git too difficult.

freeone3000 4y ago
You know how when using git you have to add tons of flags to every command to make it do what a sane person would actually want? Mercurial just does what you want.
- LaPingvino 4y ago
  I'm going to be blunt and state that what most people want is not what they actually need. If you use Git for how it was designed, the commands remain generally pretty clean. If you come from an SVN mindset, you are probably not really using Git the way it was designed, and Mercurial fits better. I have used (actually introduced) Mercurial before at a company and considered them basically equivalent enough, only to get stuck in some horrible design choices of early Mercurial (named branches and not having rebase by default). I am happy to see these elements corrected in Sapling, giving me enough confidence that I might actually use Sapling over time...
- fragmede 4y ago
  Not really, my .hgrc is about as long as my .gitrc, mostly 1 or 2-letter aliases in both. It makes both of them much easier to work with my workflow.