8 ms·

Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?

by ulkesh 7y ago

nbevans 7y ago
For one thing it offers a far cleaner user experience than Git does.
- foxhop 7y ago
  AKA the commands actually make sense, and they have sane defaults so you don't have to remember 100+ random flags.
  - jgraham 7y ago
    People always claim this in mercurial posts, but it's really hard to tell to what extent this is just that people who are using hg all the time are familiar with the hg commands and so don't notice the problems any more. As a irregular hg user, I frequently run into (or help others with) issues with the ui, like "why does `hg log require `-f` to do something useful", "how do I refer to the current head commit (protip: it's not `tip`)", "how do I see changes relative to a branch (bookmark) on a remote" and "which set of commands am I supposed to use for history rewriting nowadays and how do they work?". hg has some nice features, but the idea that it's got a fully intuitive and uniformly well designed interface is, in my experience, a total myth. Which isn't to say that git has a great CLI of course, just that the extent to which hg is better in this area is often overstated.
    - WorldMaker 7y ago
      I think it's also at least somewhat the case that hg had a great CLI when it launched and git had an abysmal CLI when it launched, but over the years and counting "necessary" hg extensions, they've both sort of converged more towards the middle: git's has only gotten better (and really only had room to get better) and hg's has mostly stayed the same, if not slowly gotten worse from the additional "overhead" of extensions. Which is that the difference between the CLIs in the early days were stark contrasts of good and bad, but now they both seem about equally mediocre, but in different ways, when directly contrasted. (Especially with the latest git release finally splitting checkout into switch and restore, they are really on increasingly similar footing.)
    - stjohnswarts 7y ago
      Same, but I don't really have that many different use cases as a developer. I wouldn't want to be the tools guy maintaining it all for 100+ developers though :)
johnchristopher 7y ago
The consensus seems to be that mercurial has a cleaner UI (options and arguments). I also read that it can get slower than git on huge repositories but I don't have benchmarks.
- alwillis 7y ago
  I also read that it can get slower than git on huge repositories but I don't have benchmarks. Not true. In fact, Mercurial is faster than Git on huge repositories; just ask Facebook--the entire Facebook application lives in a Mercurial mono repository, which wasn't possible without Git slowing to a crawl: https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/ https://engineering.fb.com/core-data/scaling-mercurial-at-fa... Turns out it's been easier for Facebook and others to optimize Mercurial over the years due to it being 95% Python, which is easier to refactor. And because of Mercurial's extensibility, it's easier to replace or optimize different components.
bjoli 7y ago
Now, I am not a programmer so I get to chose my tools all by myself without any peer preassure. In my early days I managed to destroy quite a lot (as in: counted in hours) of work with git. I switched to hg at the same time as my source control usage became more advanced, and I haven't managed to fuck anything up since. Now, I last used git extensively in 2011, and I have heard things have gotten better on the UX front. But now I am used to HG and don't have many reasons to switch. I gladly pay 20 bucks a year for having a place for mercurial repos.
- ulkesh 7y ago
  No offense meant, and I appreciate the anecdote, but I don’t feel that skill level in the technology should indicate the usefulness of the technology. I’m trying to understand more objectively than that.
  - bjoli 7y ago
    Judging from other stories, I am not alone. It seems to be a fairly typical story, even with people that use git in a professional setting. I never got comfortable using git after that, and my use case has mostly been to pull, branch, merge, push and the likes. Whenever something happens I have someone to ask, which also seems to be a common thing. A "git guy" you contact when things go wrong. With mercurial and darcs I never had that happen. Losing code is a deadly sin for a SCM should be behind at least 2 confirmation dialogues. Whenever pijul reaches 1.0 I will probably switch to that. It seems like patch theory done right.
kyrra 7y ago
Technically I think Mercurial would be better for engineering wise in the long term. Mercurial has a single implementation (Git has 5), and they greatly discourage anyone from implementing a second. This gives them a single source of truth for the implementation. Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change). It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).
- WorldMaker 7y ago
  > Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change). The file system changes were extremely low level and likely couldn't have been handled with extension hooks in Hg either (some of it, from what I read of it, would be more like the equivalent of changing the Python standard library, specifically the OS and file-system-specific bits, underneath Hg than changes to Hg or its extensions). It was also a relatively short-lived fork as it did merge upstream. > It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python). Since Microsoft has taken an active role in git development, and especially since the Windows team itself switched to git, the official Git for Windows install and support for that install has been really good. While git will likely always need some bits of Linux abstraction because how much of it's "high level" is written in Bash shell scripts and random bits of awk / sed / perl, it certainly seems that the low level stuff is less reliant on Linux abstraction than ever and is increasingly cross-platform-intended C. (Just about every major performance boost across the board has usually included rewriting to directly cross-platform code.) Python will always generally be "simpler/stabler cross-platform" for Mercurial, but git has done a remarkable job at catching up on the cross-platform space over the years.
quietbritishjim 7y ago
There are a few good things about it compared to git (and a few bad ones). One I like is that it has an excellent GUI that is cross platform, called TortoiseHg. I know hackers can be a bit snobbish about GUIs but I really think a GUI is essential for version control: flicking through the revision graph in one pane while looking at the modified files in another and a file's changes in a third is much more efficient than anything on the command line. And picking source and destination commits for a rebase is much easier visually on the commit graph than making note of hashes on the command line. Plus, at our company we do have a few people who use version control but are a bit less compsci focused. Related question: does anyone know of a good git GUI that works on Windows and Linux? (Ideally, but not essentially, free.) I tried GitKraken and it failed at the first thing I tried to do with it (I wanted to stage a file I had just created, but it didn't have a way to display untracked files).
- doubleunplussed 7y ago
  Finding a decent GUI is definitely the biggest pain point in switching to git for us. It's not just that git GUIs are lacking generally, it's that there's fragmentation - the best ones on one OS don't necessarily work on other OSs. Tortoisehg was so universal that it practically was mercurial, for the purposes of many users. We are scientists and wanting to attract contributions to our code from other scientists and grad students who can code somewhat but are unlikely to have used version control before interacting with our project. Having a universal GUI was excellent for mentoring people and spreading the knowledge around. It's going to be much harder with git (since we are moving to github - I like what sourcehut is doing for devs, but email-based pull requests will mean we get very few contributors who aren't already seasoned devs, so we have decided against it for now). From my experimenting, I'm liking Sublime Merge as my favourite git GUI so far. It's nagware (i. e. no time limit evaluation period) like sublime text, and costs US$99 to remove the nag and enable the dark theme. It is pretty and functional without being overwhelming in its interface.
  - stjohnswarts 7y ago
    Am I the only person who uses gitk and doesn't have any real problems with it?
gwbas1c 7y ago
Honestly, years ago after I took a job that uses git, I converted a Mecurial repository to github. I don't remember what tool I used, but it preserved all my history. Granted, this was a personal project and I didn't use much branching, but I remember the transition and history were pretty seamless. I originally started with Bitbucket, and then transitioned to a small hosting service after Bitbucket had extended downtime. (I just had to update my Mecurial repository to push to a new host.) Then, the transition to github was almost as easy. (If only I could remember the tool I used. Maybe my private Mecurial host allowed pulling with git? I just don't remember!)
sunflowerdeath 7y ago
What does git offer that mercurial doesn't? Of course, except a lot of popular hostings. Probably in some parallel universe mercurial could win, and people would ask same questions about git.
- stjohnswarts 7y ago
  Looks better on the resume. Both are great tools IMNSHO
zedpm 7y ago
We're currently migrating all of our mercurial repos to git. The migration is trivial and retains the full history. After working with mercurial for the last four years, I don't think it offers anything that git doesn't. I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics). Integration with third-party tools and services is nonexistent. The move to git is allowing us to leverage a world of tools, as well as allowing us to skip bringing every new developer up to speed with mercurial.
- cryptonector 7y ago
  Mindshare matters a great deal. Git won. (And thank goodness too. I don't like Mercurial's, nor Fossil's, opinionated UIs.)
- alwillis 7y ago
  I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics) Not true. Out of the box with no extensions required, Mercurial supports bookmarks, which are functionally the same as Git's branches. Also, Mercurial supports even lighter branching compared to Git using anonymous branches. This blog post from 2009 explains it all: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
  - zedpm 7y ago
    > Not true. Mostly true. I've read the post you linked to; all of those approaches have significant disadvantages compared to standard git branches. We used the bookmark-based workflow for a while, and it's simply not as good as a git branch. The evolve extension and topics were build for this reason, and they finally approach a decent workflow that allows for things like cleanly discarding experimental "branches" that have been pushed to a remote.
z3t4 7y ago
Back when I evaluated Git vs Mercurial, Git would delete uncommitted changes when changing branch. Mercurial will instead merge the unsaved changes ... I don't like either, but Mercurial seemed more forgiving. And it was almost feature complete with Git, but with a slightly easier interface. The biggest factor was however that Mercurial was platform independent, while Git was developed for Linux. One nice feature in Mercurial is that you can make commands return JSON, which makes automation easier. If I was to choose today I would choose something other then Git or Mercurial, or if I had to pick one I would pick Git simply because it's more popular. I don't think either is better or worse, they're the same but different. Do Facebook still use Mercurial!? Last time I checked they had one big monoreop, and has put engineering hours into Mercurial to help make it fast.

Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?

by ulkesh 7y ago

Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?

nbevans 7y ago

For one thing it offers a far cleaner user experience than Git does.

foxhop 7y ago
AKA the commands actually make sense, and they have sane defaults so you don't have to remember 100+ random flags.
- jgraham 7y ago
  People always claim this in mercurial posts, but it's really hard to tell to what extent this is just that people who are using hg all the time are familiar with the hg commands and so don't notice the problems any more. As a irregular hg user, I frequently run into (or help others with) issues with the ui, like "why does `hg log require `-f` to do something useful", "how do I refer to the current head commit (protip: it's not `tip`)", "how do I see changes relative to a branch (bookmark) on a remote" and "which set of commands am I supposed to use for history rewriting nowadays and how do they work?". hg has some nice features, but the idea that it's got a fully intuitive and uniformly well designed interface is, in my experience, a total myth. Which isn't to say that git has a great CLI of course, just that the extent to which hg is better in this area is often overstated.
  - WorldMaker 7y ago
    I think it's also at least somewhat the case that hg had a great CLI when it launched and git had an abysmal CLI when it launched, but over the years and counting "necessary" hg extensions, they've both sort of converged more towards the middle: git's has only gotten better (and really only had room to get better) and hg's has mostly stayed the same, if not slowly gotten worse from the additional "overhead" of extensions. Which is that the difference between the CLIs in the early days were stark contrasts of good and bad, but now they both seem about equally mediocre, but in different ways, when directly contrasted. (Especially with the latest git release finally splitting checkout into switch and restore, they are really on increasingly similar footing.)
  - stjohnswarts 7y ago
    Same, but I don't really have that many different use cases as a developer. I wouldn't want to be the tools guy maintaining it all for 100+ developers though :)

johnchristopher 7y ago

The consensus seems to be that mercurial has a cleaner UI (options and arguments). I also read that it can get slower than git on huge repositories but I don't have benchmarks.

alwillis 7y ago
I also read that it can get slower than git on huge repositories but I don't have benchmarks. Not true. In fact, Mercurial is faster than Git on huge repositories; just ask Facebook--the entire Facebook application lives in a Mercurial mono repository, which wasn't possible without Git slowing to a crawl: https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/ https://engineering.fb.com/core-data/scaling-mercurial-at-fa... Turns out it's been easier for Facebook and others to optimize Mercurial over the years due to it being 95% Python, which is easier to refactor. And because of Mercurial's extensibility, it's easier to replace or optimize different components.

bjoli 7y ago

Now, I am not a programmer so I get to chose my tools all by myself without any peer preassure. In my early days I managed to destroy quite a lot (as in: counted in hours) of work with git. I switched to hg at the same time as my source control usage became more advanced, and I haven't managed to fuck anything up since. Now, I last used git extensively in 2011, and I have heard things have gotten better on the UX front. But now I am used to HG and don't have many reasons to switch. I gladly pay 20 bucks a year for having a place for mercurial repos.

ulkesh 7y ago
No offense meant, and I appreciate the anecdote, but I don’t feel that skill level in the technology should indicate the usefulness of the technology. I’m trying to understand more objectively than that.
- bjoli 7y ago
  Judging from other stories, I am not alone. It seems to be a fairly typical story, even with people that use git in a professional setting. I never got comfortable using git after that, and my use case has mostly been to pull, branch, merge, push and the likes. Whenever something happens I have someone to ask, which also seems to be a common thing. A "git guy" you contact when things go wrong. With mercurial and darcs I never had that happen. Losing code is a deadly sin for a SCM should be behind at least 2 confirmation dialogues. Whenever pijul reaches 1.0 I will probably switch to that. It seems like patch theory done right.

kyrra 7y ago

Technically I think Mercurial would be better for engineering wise in the long term. Mercurial has a single implementation (Git has 5), and they greatly discourage anyone from implementing a second. This gives them a single source of truth for the implementation. Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change). It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).

WorldMaker 7y ago
> Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a specific spot in the code and change how things work. So I could create an extension that completely changes some aspect of how Mercurial works without needing to fork it (unlike Git, where Microsoft had to release a fork of it to support their file system change). The file system changes were extremely low level and likely couldn't have been handled with extension hooks in Hg either (some of it, from what I read of it, would be more like the equivalent of changing the Python standard library, specifically the OS and file-system-specific bits, underneath Hg than changes to Hg or its extensions). It was also a relatively short-lived fork as it did merge upstream. > It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python). Since Microsoft has taken an active role in git development, and especially since the Windows team itself switched to git, the official Git for Windows install and support for that install has been really good. While git will likely always need some bits of Linux abstraction because how much of it's "high level" is written in Bash shell scripts and random bits of awk / sed / perl, it certainly seems that the low level stuff is less reliant on Linux abstraction than ever and is increasingly cross-platform-intended C. (Just about every major performance boost across the board has usually included rewriting to directly cross-platform code.) Python will always generally be "simpler/stabler cross-platform" for Mercurial, but git has done a remarkable job at catching up on the cross-platform space over the years.

quietbritishjim 7y ago

There are a few good things about it compared to git (and a few bad ones). One I like is that it has an excellent GUI that is cross platform, called TortoiseHg. I know hackers can be a bit snobbish about GUIs but I really think a GUI is essential for version control: flicking through the revision graph in one pane while looking at the modified files in another and a file's changes in a third is much more efficient than anything on the command line. And picking source and destination commits for a rebase is much easier visually on the commit graph than making note of hashes on the command line. Plus, at our company we do have a few people who use version control but are a bit less compsci focused. Related question: does anyone know of a good git GUI that works on Windows and Linux? (Ideally, but not essentially, free.) I tried GitKraken and it failed at the first thing I tried to do with it (I wanted to stage a file I had just created, but it didn't have a way to display untracked files).

doubleunplussed 7y ago
Finding a decent GUI is definitely the biggest pain point in switching to git for us. It's not just that git GUIs are lacking generally, it's that there's fragmentation - the best ones on one OS don't necessarily work on other OSs. Tortoisehg was so universal that it practically was mercurial, for the purposes of many users. We are scientists and wanting to attract contributions to our code from other scientists and grad students who can code somewhat but are unlikely to have used version control before interacting with our project. Having a universal GUI was excellent for mentoring people and spreading the knowledge around. It's going to be much harder with git (since we are moving to github - I like what sourcehut is doing for devs, but email-based pull requests will mean we get very few contributors who aren't already seasoned devs, so we have decided against it for now). From my experimenting, I'm liking Sublime Merge as my favourite git GUI so far. It's nagware (i. e. no time limit evaluation period) like sublime text, and costs US$99 to remove the nag and enable the dark theme. It is pretty and functional without being overwhelming in its interface.
- stjohnswarts 7y ago
  Am I the only person who uses gitk and doesn't have any real problems with it?

gwbas1c 7y ago

Honestly, years ago after I took a job that uses git, I converted a Mecurial repository to github. I don't remember what tool I used, but it preserved all my history. Granted, this was a personal project and I didn't use much branching, but I remember the transition and history were pretty seamless. I originally started with Bitbucket, and then transitioned to a small hosting service after Bitbucket had extended downtime. (I just had to update my Mecurial repository to push to a new host.) Then, the transition to github was almost as easy. (If only I could remember the tool I used. Maybe my private Mecurial host allowed pulling with git? I just don't remember!)

sunflowerdeath 7y ago

What does git offer that mercurial doesn't? Of course, except a lot of popular hostings. Probably in some parallel universe mercurial could win, and people would ask same questions about git.

stjohnswarts 7y ago
Looks better on the resume. Both are great tools IMNSHO

zedpm 7y ago

We're currently migrating all of our mercurial repos to git. The migration is trivial and retains the full history. After working with mercurial for the last four years, I don't think it offers anything that git doesn't. I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics). Integration with third-party tools and services is nonexistent. The move to git is allowing us to leverage a world of tools, as well as allowing us to skip bringing every new developer up to speed with mercurial.

cryptonector 7y ago
Mindshare matters a great deal. Git won. (And thank goodness too. I don't like Mercurial's, nor Fossil's, opinionated UIs.)
alwillis 7y ago
I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics) Not true. Out of the box with no extensions required, Mercurial supports bookmarks, which are functionally the same as Git's branches. Also, Mercurial supports even lighter branching compared to Git using anonymous branches. This blog post from 2009 explains it all: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
- zedpm 7y ago
  > Not true. Mostly true. I've read the post you linked to; all of those approaches have significant disadvantages compared to standard git branches. We used the bookmark-based workflow for a while, and it's simply not as good as a git branch. The evolve extension and topics were build for this reason, and they finally approach a decent workflow that allows for things like cleanly discarding experimental "branches" that have been pushed to a remote.

z3t4 7y ago

Back when I evaluated Git vs Mercurial, Git would delete uncommitted changes when changing branch. Mercurial will instead merge the unsaved changes ... I don't like either, but Mercurial seemed more forgiving. And it was almost feature complete with Git, but with a slightly easier interface. The biggest factor was however that Mercurial was platform independent, while Git was developed for Linux. One nice feature in Mercurial is that you can make commands return JSON, which makes automation easier. If I was to choose today I would choose something other then Git or Mercurial, or if I had to pick one I would pick Git simply because it's more popular. I don't think either is better or worse, they're the same but different. Do Facebook still use Mercurial!? Last time I checked they had one big monoreop, and has put engineering hours into Mercurial to help make it fast.