24 ms·

Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easie

Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind. When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.

jchw 7y ago
I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit tracks its own history through rewrites. You get cool commands like absorb and evolve. It’s easier to extend than Git. The only downside to modern Mercurial I can think of is it’s still slower than Git, by at least a bit. But it can scale incredibly far with its extensibility. For example, what Facebook did: https://code.fb.com/core-data/scaling-mercurial-at-facebook/ https://code.fb.com/core-data/scaling-mercurial-at-facebook/ So why does it never seem to get consideration? I guess it’s because of the insane proliferation of Github and Linux, which is definitely more a blessing than a curse. But it’s weird. Back in the CVS and SVN days, it didn’t seem like there was ever going to be a ‘network effect’ for source control like there is today. I kind of wish Gitlab would implement Mercurial support. I bet it would help Mercurial gain more adoption within teams working on closed source projects. I know Bitbucket does, but to be honest that doesn’t really appeal to me much.
- darkpuma 7y ago
  Hg and git have near feature parity, so I don't really lament Hg's loss so much. Sure Hg's CLI is a little bit better, but beyond that it never really offered any really compelling features over git. Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. Fossil is another matter. Fossil defies pithy car analogies. Integrating the bug tracker into the version control alone is a game changer, and that's not even all that Fossil does.
  - jchw 7y ago
    Hg actually does go beyond Git in many areas; I did outline a few but my favorites are the improved commit model (stages, natural branching, rewrite tracking,) the commands Git doesn’t have (absorb, evolve,) and the extensibility (see Facebook extensions.) Sure, the model is similar and Fossil is different. But that is kind of an important note. If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems. In most setups, the bug tracker and source control are separate, but that doesn’t mean you can’t get bugtracking alongside code either, GitLab provides everything from bugtracking to CI to deploying stuff to Kubernetes. Not to say Fossil isn’t cool or doesn’t have its place, but if I disagree with the philosophy (and I do, fundamentally,) then I don’t feel like I lose much using alternative software suites.
    - darkpuma 7y ago
      > If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems. Or Fossil provides a superset of the others. Like comparing a corkscrew, which only opens bottles of wine, to a swiss army knife that has a corkscrew. They both solve the same problem, but one of them also solves other problems and is generally a more useful tool to keep around in your pocket. The world didn't lose much with Hg losing to git. But with Fossil losing, we lost a great deal. As a consequence we have a world where people feel locked into the proprietary bug trackers their git host provides. Had Hg prevailed, that situation would be no different. The only way the world would be different if Hg had prevailed would be fewer posts on HN whining about git's interface being obtuse. Not really a substantially different reality, is it?
      - jacobush 7y ago
        I used Fossil but it became very very slow when the repo size crawled near a gigabyte.
      - jchw 7y ago
        I don’t think people feel locked into proprietary bug tracking, they just choose it out of convenience. You can export data from Github or Gitlab. I mean hell, trac and redmine have been around forever now. Is an open source wiki+bugtracker that revolutionary? My best guess is that there’s some benefit of merging the source control in, but I’m not sure; it’s not like other environments can’t provide integrated bug tracking.
- avar 7y ago
  > Mercurial feels like it should be the winner. The commands are more uniform and predictable. Keith Packard's "Repository Formats Matter" post nicely captures how meaningless it is to focus on this sort of thing in the long term: https://keithp.com/blogs/Repository_Formats_Matter/ https://keithp.com/blogs/Repository_Formats_Matter/ I.e. yes Git has some UI issues, but those are fixable, whereas e.g. Subversion's UI was way better than Git in the early days, but its repository format limitations inherently weren't fixable. > Mercurial has a concept of commit stages to make history rewriting safer. Yeah that's a really neat feature. For what it's worth some people at Google seem to be working on trying to get an equivalent feature into Git. > For example, what Facebook did[...] Much of what drove Facebook to Mercurial has since been addressed, e.g. "status" times being slow due to lack of inotify-like integration. That's now a feature of core git. Some of the rest is being worked on and actively upstreamed, e.g. from the GVFS effort: https://vfsforgit.org https://vfsforgit.org
  - mannykannot 7y ago
    Your response to the first point appears to explain why Git largely replaced Subversion, but it is not clear that it applies to Mercurial.
    - avar 7y ago
      I'm not saying it won't, just that transitory UI issues are unlikely to drive a mass exodus from one source control system to another. To reference a reply of mine to your sibling comment[1], it would have been like going through a lot of trouble to move from Mercurial to Git some years ago just because Mercurial's terminal UI didn't use coloring. 1. https://news.ycombinator.com/item?id=19908932 https://news.ycombinator.com/item?id=19908932
  - jrochkind1 7y ago
    > I.e. yes Git has some UI issues, but those are fixable In theory, yes. However, a decade on an I'm not sure any UI issues have been fixed? It turns out 'legacy' is a hard problem, including just for UI "porcelain". In part because people are used to what there is. (Which is a reason it's hard to get people to switch to something that isn't git either -- enough people have figured out how to do what they need with git as it is, and most people don't like having to learn new tooling). Everyone agrees that moving from svn to git was a net positive, nobody likes svn better. Git is pretty good. But it's UI can be weird. And I am pretty sure if we check back in another 10 years, if people are still using git, it will be with the same basic UI model, little "fixable" will have been fixed. Doesn't mean it'll be a disaster, we're doing okay with git. But I don't think the "UI issues are fixable" argument carries much weight here. (Other alternatives may have been better, it can sometimes be a mystery or subject to debate why one product "wins".)
- sc11 7y ago
  > I kind of wish Gitlab would implement Mercurial support. I bet it would help Mercurial gain more adoption within teams working on closed source projects. I know Bitbucket does, but to be honest that doesn’t really appeal to me much. There is some work being done on it, including a prototype: https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_155238895 https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_15...
- phpdave11 7y ago
  You can use Mercurial with GitHub by using the hg-git plugin, which lets you push to and pull from a Git server repository from Mercurial. It’s a really nice tool that I’ve been using for several years to push to git repositories.
- jhauris 7y ago
  https://sr.ht https://sr.ht supports mercurial now. I haven't used it yet, but it's a nice OSS option.
- andrewla 7y ago
  > I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands. But in the end it's deceptive; git, ugly as it is, reflects the underlying data model. Once you understand that data model, and how the basic commands manipulate that model, then it becomes a very natural language for manipulating the commit chain. If there's a downside, it's that git doesn't let you get away for too long without learning the data model, while Mercurial lets you live in blessed ignorance until the first time it doesn't work like svn does, and then you're stuck because its data model is not as cleanly exposed, so you need to gently massage it into a good state rather than just surgically moving it to where you want it to be.
  - fouronnes3 7y ago
    Even if you understand the data model perfectly, git still has terrible UX. reset can do 3 different things, a "remote" can mean 3 different things depending on context... I could go on all day. Just the fact that there are parodies of git man pages should drive the point home. (Disclaimer: I love git). Oh and what the hell is 'git rerere' anyway?
    - dllthomas 7y ago
      You love git because your experience, overall, is far from terrible. It's true that there are a lot of inconsistencies to memorize, and that's a worse UX than the equivalent without those inconsistencies, but that only matters so much. We both speak English - we can cope with inconsistencies in a language.
      - jchw 7y ago
        I don't love Git because it’s got a great UX. I love Git because of what can be done once you get past the awful UX. The first year or two of Git usage ended in many, many incidents of lost work. That is not good UX for source control, its the most catastrophic UX imaginable for something designed to track source changes... That’s why the site this post is about exists. If you don’t know about reflog, you are severely disadvantaged... and many of my coworkers at my previous employer certainly did not.
- Annatar 7y ago
  Yep. Mercurial is the better revision control system (although not a faster one). It deserves all the attention this git piece of overcomplicated crap is getting. And let's face it, in what is one of penultimate gestures of pandering fanboyism, git would never be so popular were it not poorly copied from Larry McVoy by Linus Torvalds and used for Linux development. Even Larry's revision control deserves more love and attention for being superior. Yet another trash fire.
- MikusR 7y ago
  When i started using version control for my plain text notes, I initially settled on Mercurial (because of it's supposed better support for Windows), but turns out it doesn't support unicode filenames while git does. So I went with git.
- sanderjd 7y ago
  Yep, mercurial really is better, but it is also noticeably slower. I used git for about a decade, and now use hg at my job. Recently, I used used git again while playing around with something over a weekend. I instantly remembered why I loved it so much. There is really something to be said for commands resolving practically before you have noticed you pressed enter. I wonder if this is inherent or accidental; I don't know the mercurial data model well enough to understand why it would be necessarily laggier.
  - alexhutcheson 7y ago
    Python vs. C makes a big difference.
- otabdeveloper1 7y ago
  > The commands are more uniform and predictable. Git won because it was a) unopinionated and b) powerful enough to support arbitrary workflows for any enterprise. For the enterprise, being 'uniform and predictable' is way, way, way down lower on the list of important criteria in version control. (And in fact may even be a negative, due to the weird legacy workflows many enterprises have.)
- js2 7y ago
  I'm an early git contributor and long time user. At the time I picked it up, I was following and using hg as well. I found git easier to learn and use. Git has just a few basic concepts underlying how it works. Once I learned blobs, trees, commits, the index, and references (branches, tags, reflog, etc), I understood the model. It wasn't hard to grok a local vs remote repo, how history was a dag, and so forth. From there, I realized all the crazy commands, the baroque UI, these were all just ways of manipulating those objects in various ways. I could always figure out how to make git do what I wanted. It never fought me or tried to tell me I couldn't do something. hg, by contrast, I felt was always trying to hold my hand. Its model was harder to understand. It required me to adapt to its workflow, instead of allowing me to adapt it to mine. It was generally much less flexible. I found everything about git more Unix-philosophy like. I understand completely if you don't want to think about your VCS and just want it to record your changes and otherwise get out of your way, but I wanted a more flexible and powerful tool.
- emilycook 7y ago
  > I kind of wish GitLab would implement Mercurial support Hi! GitLab employee here. Mercurial support has been a hot-ish topic internally. If you want to weigh in then please comment on this Issue, since Issue interaction plays a big part of how we prioritize https://gitlab.com/gitlab-org/gitlab-ce/issues/31600 https://gitlab.com/gitlab-org/gitlab-ce/issues/31600 (edit: I'm an idiot I should've read the full thread first since someone already linked it. gonna leave it up anyway)
- zapita 7y ago
  I used Mercurial exclusively for a long time. I reluctantly switched to Git when it became obvious Github was the place to be if you wanted your open-source project to get any attention. I think the way forward for Mercurial would be to become a Git frontend, or "porcelain" as they call it. That way we would get the best of both worlds: the ubiquitous git format and hosting infrastructure; and the superior UI and workflow of Mercurial. I'm sure it would be a difficult undertaking, and might require difficult trade offs between compatibility, performance and usability. But I think it would be worth it. For one, Mercurial would become relevant again, and probably get a lot of new users. A lot of users would probably come back. And Git users would also benefit from the renewed competition between competing frontends.
- paulddraper 7y ago
  > So why does it never seem to get consideration? I guess it’s because of the insane proliferation of Github and Linux Part of it is not wanted to learn multiple VCS's. Part of it is Github. Part of it is performance. I honestly believe that if Github supported Mercurial, or if Bitbucket had "won" over Github, then Git:Mercurial would be something like 4:1.
teekert 7y ago
Git is ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance and it will work for you. Actually I find this with many programming concepts.
- masklinn 7y ago
  Meh. Git has a shitty UI when you start with, and it still has a shitty UI years down the line. The underlying model is neat and interesting, but that you have to know it to find any usability or elegance is an indictment.
  - rusk 7y ago
    Hence the name I guess ... yeah it's ugly and annoying but you're stuck with it because it's great. Kind of like Linus himself I guess ... I wonder if that's the joke.
    - gjm11 7y ago
      > I wonder if that's the joke. Yup. According to Wikipedia, Linus said: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
    - masklinn 7y ago
      > you're stuck with it because it's great. We're stuck with it because of network effects. Git is absolutely not great.
      - JohnFen 7y ago
        I think git is great. But that might only be because all the other version control systems I've used are worse...
  - Grangar 7y ago
    Don't use the UI. Use the CLI. It sucked at first but made my experience tenfold easier down the line.
sAbakumoff 7y ago
how about star team? L)
JohnFen 7y ago
I agree. I still have to use svn in my workplace, but I use git for my own stuff. When things go wrong, I find it easier to fix it with git than svn.

jchw 7y ago

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit tracks its own history through rewrites. You get cool commands like absorb and evolve. It’s easier to extend than Git. The only downside to modern Mercurial I can think of is it’s still slower than Git, by at least a bit. But it can scale incredibly far with its extensibility. For example, what Facebook did: https://code.fb.com/core-data/scaling-mercurial-at-facebook/ https://code.fb.com/core-data/scaling-mercurial-at-facebook/ So why does it never seem to get consideration? I guess it’s because of the insane proliferation of Github and Linux, which is definitely more a blessing than a curse. But it’s weird. Back in the CVS and SVN days, it didn’t seem like there was ever going to be a ‘network effect’ for source control like there is today. I kind of wish Gitlab would implement Mercurial support. I bet it would help Mercurial gain more adoption within teams working on closed source projects. I know Bitbucket does, but to be honest that doesn’t really appeal to me much.

darkpuma 7y ago
Hg and git have near feature parity, so I don't really lament Hg's loss so much. Sure Hg's CLI is a little bit better, but beyond that it never really offered any really compelling features over git. Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. Fossil is another matter. Fossil defies pithy car analogies. Integrating the bug tracker into the version control alone is a game changer, and that's not even all that Fossil does.
- jchw 7y ago
  Hg actually does go beyond Git in many areas; I did outline a few but my favorites are the improved commit model (stages, natural branching, rewrite tracking,) the commands Git doesn’t have (absorb, evolve,) and the extensibility (see Facebook extensions.) Sure, the model is similar and Fossil is different. But that is kind of an important note. If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems. In most setups, the bug tracker and source control are separate, but that doesn’t mean you can’t get bugtracking alongside code either, GitLab provides everything from bugtracking to CI to deploying stuff to Kubernetes. Not to say Fossil isn’t cool or doesn’t have its place, but if I disagree with the philosophy (and I do, fundamentally,) then I don’t feel like I lose much using alternative software suites.
  - darkpuma 7y ago
    > If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems. Or Fossil provides a superset of the others. Like comparing a corkscrew, which only opens bottles of wine, to a swiss army knife that has a corkscrew. They both solve the same problem, but one of them also solves other problems and is generally a more useful tool to keep around in your pocket. The world didn't lose much with Hg losing to git. But with Fossil losing, we lost a great deal. As a consequence we have a world where people feel locked into the proprietary bug trackers their git host provides. Had Hg prevailed, that situation would be no different. The only way the world would be different if Hg had prevailed would be fewer posts on HN whining about git's interface being obtuse. Not really a substantially different reality, is it?
    - jacobush 7y ago
      I used Fossil but it became very very slow when the repo size crawled near a gigabyte.
    - jchw 7y ago
      I don’t think people feel locked into proprietary bug tracking, they just choose it out of convenience. You can export data from Github or Gitlab. I mean hell, trac and redmine have been around forever now. Is an open source wiki+bugtracker that revolutionary? My best guess is that there’s some benefit of merging the source control in, but I’m not sure; it’s not like other environments can’t provide integrated bug tracking.
avar 7y ago
> Mercurial feels like it should be the winner. The commands are more uniform and predictable. Keith Packard's "Repository Formats Matter" post nicely captures how meaningless it is to focus on this sort of thing in the long term: https://keithp.com/blogs/Repository_Formats_Matter/ https://keithp.com/blogs/Repository_Formats_Matter/ I.e. yes Git has some UI issues, but those are fixable, whereas e.g. Subversion's UI was way better than Git in the early days, but its repository format limitations inherently weren't fixable. > Mercurial has a concept of commit stages to make history rewriting safer. Yeah that's a really neat feature. For what it's worth some people at Google seem to be working on trying to get an equivalent feature into Git. > For example, what Facebook did[...] Much of what drove Facebook to Mercurial has since been addressed, e.g. "status" times being slow due to lack of inotify-like integration. That's now a feature of core git. Some of the rest is being worked on and actively upstreamed, e.g. from the GVFS effort: https://vfsforgit.org https://vfsforgit.org
- mannykannot 7y ago
  Your response to the first point appears to explain why Git largely replaced Subversion, but it is not clear that it applies to Mercurial.
  - avar 7y ago
    I'm not saying it won't, just that transitory UI issues are unlikely to drive a mass exodus from one source control system to another. To reference a reply of mine to your sibling comment[1], it would have been like going through a lot of trouble to move from Mercurial to Git some years ago just because Mercurial's terminal UI didn't use coloring. 1. https://news.ycombinator.com/item?id=19908932 https://news.ycombinator.com/item?id=19908932
- jrochkind1 7y ago
  > I.e. yes Git has some UI issues, but those are fixable In theory, yes. However, a decade on an I'm not sure any UI issues have been fixed? It turns out 'legacy' is a hard problem, including just for UI "porcelain". In part because people are used to what there is. (Which is a reason it's hard to get people to switch to something that isn't git either -- enough people have figured out how to do what they need with git as it is, and most people don't like having to learn new tooling). Everyone agrees that moving from svn to git was a net positive, nobody likes svn better. Git is pretty good. But it's UI can be weird. And I am pretty sure if we check back in another 10 years, if people are still using git, it will be with the same basic UI model, little "fixable" will have been fixed. Doesn't mean it'll be a disaster, we're doing okay with git. But I don't think the "UI issues are fixable" argument carries much weight here. (Other alternatives may have been better, it can sometimes be a mystery or subject to debate why one product "wins".)
sc11 7y ago
> I kind of wish Gitlab would implement Mercurial support. I bet it would help Mercurial gain more adoption within teams working on closed source projects. I know Bitbucket does, but to be honest that doesn’t really appeal to me much. There is some work being done on it, including a prototype: https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_155238895 https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_15...
phpdave11 7y ago
You can use Mercurial with GitHub by using the hg-git plugin, which lets you push to and pull from a Git server repository from Mercurial. It’s a really nice tool that I’ve been using for several years to push to git repositories.
jhauris 7y ago
https://sr.ht https://sr.ht supports mercurial now. I haven't used it yet, but it's a nice OSS option.
andrewla 7y ago
> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands. But in the end it's deceptive; git, ugly as it is, reflects the underlying data model. Once you understand that data model, and how the basic commands manipulate that model, then it becomes a very natural language for manipulating the commit chain. If there's a downside, it's that git doesn't let you get away for too long without learning the data model, while Mercurial lets you live in blessed ignorance until the first time it doesn't work like svn does, and then you're stuck because its data model is not as cleanly exposed, so you need to gently massage it into a good state rather than just surgically moving it to where you want it to be.
- fouronnes3 7y ago
  Even if you understand the data model perfectly, git still has terrible UX. reset can do 3 different things, a "remote" can mean 3 different things depending on context... I could go on all day. Just the fact that there are parodies of git man pages should drive the point home. (Disclaimer: I love git). Oh and what the hell is 'git rerere' anyway?
  - dllthomas 7y ago
    You love git because your experience, overall, is far from terrible. It's true that there are a lot of inconsistencies to memorize, and that's a worse UX than the equivalent without those inconsistencies, but that only matters so much. We both speak English - we can cope with inconsistencies in a language.
    - jchw 7y ago
      I don't love Git because it’s got a great UX. I love Git because of what can be done once you get past the awful UX. The first year or two of Git usage ended in many, many incidents of lost work. That is not good UX for source control, its the most catastrophic UX imaginable for something designed to track source changes... That’s why the site this post is about exists. If you don’t know about reflog, you are severely disadvantaged... and many of my coworkers at my previous employer certainly did not.
Annatar 7y ago
Yep. Mercurial is the better revision control system (although not a faster one). It deserves all the attention this git piece of overcomplicated crap is getting. And let's face it, in what is one of penultimate gestures of pandering fanboyism, git would never be so popular were it not poorly copied from Larry McVoy by Linus Torvalds and used for Linux development. Even Larry's revision control deserves more love and attention for being superior. Yet another trash fire.
MikusR 7y ago
When i started using version control for my plain text notes, I initially settled on Mercurial (because of it's supposed better support for Windows), but turns out it doesn't support unicode filenames while git does. So I went with git.
sanderjd 7y ago
Yep, mercurial really is better, but it is also noticeably slower. I used git for about a decade, and now use hg at my job. Recently, I used used git again while playing around with something over a weekend. I instantly remembered why I loved it so much. There is really something to be said for commands resolving practically before you have noticed you pressed enter. I wonder if this is inherent or accidental; I don't know the mercurial data model well enough to understand why it would be necessarily laggier.
- alexhutcheson 7y ago
  Python vs. C makes a big difference.
otabdeveloper1 7y ago
> The commands are more uniform and predictable. Git won because it was a) unopinionated and b) powerful enough to support arbitrary workflows for any enterprise. For the enterprise, being 'uniform and predictable' is way, way, way down lower on the list of important criteria in version control. (And in fact may even be a negative, due to the weird legacy workflows many enterprises have.)
js2 7y ago
I'm an early git contributor and long time user. At the time I picked it up, I was following and using hg as well. I found git easier to learn and use. Git has just a few basic concepts underlying how it works. Once I learned blobs, trees, commits, the index, and references (branches, tags, reflog, etc), I understood the model. It wasn't hard to grok a local vs remote repo, how history was a dag, and so forth. From there, I realized all the crazy commands, the baroque UI, these were all just ways of manipulating those objects in various ways. I could always figure out how to make git do what I wanted. It never fought me or tried to tell me I couldn't do something. hg, by contrast, I felt was always trying to hold my hand. Its model was harder to understand. It required me to adapt to its workflow, instead of allowing me to adapt it to mine. It was generally much less flexible. I found everything about git more Unix-philosophy like. I understand completely if you don't want to think about your VCS and just want it to record your changes and otherwise get out of your way, but I wanted a more flexible and powerful tool.
emilycook 7y ago
> I kind of wish GitLab would implement Mercurial support Hi! GitLab employee here. Mercurial support has been a hot-ish topic internally. If you want to weigh in then please comment on this Issue, since Issue interaction plays a big part of how we prioritize https://gitlab.com/gitlab-org/gitlab-ce/issues/31600 https://gitlab.com/gitlab-org/gitlab-ce/issues/31600 (edit: I'm an idiot I should've read the full thread first since someone already linked it. gonna leave it up anyway)
zapita 7y ago
I used Mercurial exclusively for a long time. I reluctantly switched to Git when it became obvious Github was the place to be if you wanted your open-source project to get any attention. I think the way forward for Mercurial would be to become a Git frontend, or "porcelain" as they call it. That way we would get the best of both worlds: the ubiquitous git format and hosting infrastructure; and the superior UI and workflow of Mercurial. I'm sure it would be a difficult undertaking, and might require difficult trade offs between compatibility, performance and usability. But I think it would be worth it. For one, Mercurial would become relevant again, and probably get a lot of new users. A lot of users would probably come back. And Git users would also benefit from the renewed competition between competing frontends.
paulddraper 7y ago
> So why does it never seem to get consideration? I guess it’s because of the insane proliferation of Github and Linux Part of it is not wanted to learn multiple VCS's. Part of it is Github. Part of it is performance. I honestly believe that if Github supported Mercurial, or if Bitbucket had "won" over Github, then Git:Mercurial would be something like 4:1.

teekert 7y ago

Git is ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance and it will work for you. Actually I find this with many programming concepts.

masklinn 7y ago
Meh. Git has a shitty UI when you start with, and it still has a shitty UI years down the line. The underlying model is neat and interesting, but that you have to know it to find any usability or elegance is an indictment.
- rusk 7y ago
  Hence the name I guess ... yeah it's ugly and annoying but you're stuck with it because it's great. Kind of like Linus himself I guess ... I wonder if that's the joke.
  - gjm11 7y ago
    > I wonder if that's the joke. Yup. According to Wikipedia, Linus said: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."
  - masklinn 7y ago
    > you're stuck with it because it's great. We're stuck with it because of network effects. Git is absolutely not great.
    - JohnFen 7y ago
      I think git is great. But that might only be because all the other version control systems I've used are worse...
- Grangar 7y ago
  Don't use the UI. Use the CLI. It sucked at first but made my experience tenfold easier down the line.

sAbakumoff 7y ago

how about star team? L)

JohnFen 7y ago

I agree. I still have to use svn in my workplace, but I use git for my own stuff. When things go wrong, I find it easier to fix it with git than svn.