4 ms·

I literally forgot about Mercurial. It’s been years since I’ve even heard it mentioned. Are there any strong arguments for using it over Git these days? Is this

I literally forgot about Mercurial. It’s been years since I’ve even heard it mentioned. Are there any strong arguments for using it over Git these days? Is this just about supporting legacy code bases. I’m sure there must be a way to migrate to Git [and maintain history]. I’m not trolling, I would love to hear from someone who prefers Mercurial over Git as to how it benefits them.

dragonsh 7y ago
Our company use mercurial and we are very happy with it. Mercurial has evolved and it's UI is still better than git. We use it due to following reasons: 1. Very easy to use and very well documented with a book.[1] 2. Mercurial good python philosophy of "explicit is better than implicit". This means every merge also needs to explicitly committed preserving history. Our team likes it. 3. Better multi-platform support. 4. Easy to extend to fit specific workflow. 5. Just run hg serve and access a beautiful web interface to review code. No need of external tools. In this aspect though fossil-scm [2] is ahead of both git and mercurial. [1] http://hgbook.red-bean.com/ http://hgbook.red-bean.com/ [2] http://fossil-scm.org/home/doc/trunk/www/index.wiki http://fossil-scm.org/home/doc/trunk/www/index.wiki
steve_adams_86 7y ago
In my limited experience with Hg, I thought it had a well designed, human-friendly interface. After a decade with git, I still feel like it's an ugly, awkward tool that just gets the job done and I still occasionally make weird mistakes with it. I'm not sure that's the case with other tools I've been using this long. Git has a pretty gross interface, such that people have struggled to make it nicer to use with GUIs for as long as I can remember. I also feel as though every junior developer has panic inducing moments with git where they think they've lost work or something terrifying like that. It's like a hazing ritual in programming. Wait for git to give you a heart attack. If you survive, you're one of us. Hg didn't really give me that impression at all and I was excited to begin using it more, but like with most technologies I want to adopt, work and family won and I stuck with git at work and otherwise had no time to use Hg more. It seems like git won largely because it has the right buy-in from the right people.
- jason_s 7y ago
  ...and because Atlassian let Bitbucket's Hg support wither and die.
  - Drdrdrq 7y ago
    I would say GitHub was the deciding factor. Atlassian at least supported hg, though BB never impressed me.
elygre 7y ago
Java OpenJDK development has been on Mercurial, and ponders moving to Git. In typical OpenJDK-fashion, the process is thoroughly examined and discussed. More information in for example * https://openjdk.java.net/jeps/357 https://openjdk.java.net/jeps/357 * https://github.com/openjdk/skara https://github.com/openjdk/skara * http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-2019-08-skara.pdf http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-2019....
- dcminter 7y ago
  Last time I tried to pull down the JDK source it required me to install mercurial (fair enough) but then to install a "forests" extension which no longer appeared to be available (or at least not from the documented location). Not strictly a Mercurial issue, but using the platform that your audience is already familiar with has a lot to recommend it.
muxator 7y ago
I have been using mercurial for more than a decade now. I just install hg-git, work on my local mercurial repo, push & pull to git, without any friction with anyone in my team. Mercurial simply stayed my secret tool for version control, without anyone noticing. - the command line is unsurprising and coherent - the UX in the terminal is nice (with tweakdefaults=true, you have colored word diffs, and nice curses interface for commit, uncommit, amend, --interactive) - integrated web ui via "hg serve" - compatible with git. There are margin for improvement here: hg-git can do everything but you have to be an advanced user. - advanced workflows are not only possible, but easier and safer, due to non destructive history editing - TortoiseHg is a honest GUI. Most advanced workflows are even easier there. Works on windows, so it's a good way of introducing less advanced users to version control.

dragonsh 7y ago

Our company use mercurial and we are very happy with it. Mercurial has evolved and it's UI is still better than git. We use it due to following reasons: 1. Very easy to use and very well documented with a book.[1] 2. Mercurial good python philosophy of "explicit is better than implicit". This means every merge also needs to explicitly committed preserving history. Our team likes it. 3. Better multi-platform support. 4. Easy to extend to fit specific workflow. 5. Just run hg serve and access a beautiful web interface to review code. No need of external tools. In this aspect though fossil-scm [2] is ahead of both git and mercurial. [1] http://hgbook.red-bean.com/ http://hgbook.red-bean.com/ [2] http://fossil-scm.org/home/doc/trunk/www/index.wiki http://fossil-scm.org/home/doc/trunk/www/index.wiki

steve_adams_86 7y ago

In my limited experience with Hg, I thought it had a well designed, human-friendly interface. After a decade with git, I still feel like it's an ugly, awkward tool that just gets the job done and I still occasionally make weird mistakes with it. I'm not sure that's the case with other tools I've been using this long. Git has a pretty gross interface, such that people have struggled to make it nicer to use with GUIs for as long as I can remember. I also feel as though every junior developer has panic inducing moments with git where they think they've lost work or something terrifying like that. It's like a hazing ritual in programming. Wait for git to give you a heart attack. If you survive, you're one of us. Hg didn't really give me that impression at all and I was excited to begin using it more, but like with most technologies I want to adopt, work and family won and I stuck with git at work and otherwise had no time to use Hg more. It seems like git won largely because it has the right buy-in from the right people.

jason_s 7y ago
...and because Atlassian let Bitbucket's Hg support wither and die.
- Drdrdrq 7y ago
  I would say GitHub was the deciding factor. Atlassian at least supported hg, though BB never impressed me.

elygre 7y ago

Java OpenJDK development has been on Mercurial, and ponders moving to Git. In typical OpenJDK-fashion, the process is thoroughly examined and discussed. More information in for example * https://openjdk.java.net/jeps/357 https://openjdk.java.net/jeps/357 * https://github.com/openjdk/skara https://github.com/openjdk/skara * http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-2019-08-skara.pdf http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-2019....

dcminter 7y ago
Last time I tried to pull down the JDK source it required me to install mercurial (fair enough) but then to install a "forests" extension which no longer appeared to be available (or at least not from the documented location). Not strictly a Mercurial issue, but using the platform that your audience is already familiar with has a lot to recommend it.

muxator 7y ago

I have been using mercurial for more than a decade now. I just install hg-git, work on my local mercurial repo, push & pull to git, without any friction with anyone in my team. Mercurial simply stayed my secret tool for version control, without anyone noticing. - the command line is unsurprising and coherent - the UX in the terminal is nice (with tweakdefaults=true, you have colored word diffs, and nice curses interface for commit, uncommit, amend, --interactive) - integrated web ui via "hg serve" - compatible with git. There are margin for improvement here: hg-git can do everything but you have to be an advanced user. - advanced workflows are not only possible, but easier and safer, due to non destructive history editing - TortoiseHg is a honest GUI. Most advanced workflows are even easier there. Works on windows, so it's a good way of introducing less advanced users to version control.