11 ms·

I've never heard of mercurial until this post, I've been using git for version control and it does the job really well. To those who use mercurial over git, wh

by talhah 6y ago

I've never heard of mercurial until this post, I've been using git for version control and it does the job really well. To those who use mercurial over git, why?

jmercouris 6y ago
A much better UI. Git won because of the influence of the Linux kernel developers, that's all.
- xyst 6y ago
  The influence of a single linux kernel developer is the reason it's adoption is so high - Linus Torvalds.
  - tux1968 6y ago
    That's much too simplistic. For instance Linus also denounces C++ and programmers don't fall into line behind him on that front. He is influential, but could not have caused the monumental shift in version control without producing a phenomenal tool to do the job. Git largely won on its overall merit, despite having some obvious UI warts.
  - kbenson 6y ago
    Eh, that's a bit reductionist. Git was developed by Tovalds because BitKeeper had shortcomings he kept grating against, and it really needed to be a DVCS for kernel development. So he created something that fit the kernel development needs well, and it happened to also fit the needs of other companies as well. That it was free and open source was icing on the cake. That Torvalds created it just meant that there was already a wide audience of people willing to consider it and give it a fair shake initially. I'm sure it didn't hurt that Torvalds had many years of experience dealing with lots of the shortcomings of different version control systems and their shortcomings in what is probably one of the more extreme version control situations, and is also known for optimizing the hard parts of things. It was really the perfect storm for good open source software. A highly skilled developer with massive amounts of domain experience that is highly motivated to solve the problem. What you often get in those situations is something that is an obvious step up from the status quo, at least of free offerings, and often matching the paid offerings if they are more advanced. If it wasn't Torvalds, it just would have taken longer to take over.
    - rleigh 6y ago
      As you say, it can't be understated just how much of a conceptual leap git was. It wasn't developed in a vacuum. And there were several interesting distributed open source version control systems around at the time. After moving on from CVS and Subversion, I tried using Arch (tla) for a project. It was interesting, but still tied to the old way of thinking of version control as a series of deltas, both in its conceptual model and in its storage implementation. In fact, its storage was a tarball of a "base revision" plus a series of patches. Checking out a branch meant unpacking the tarball and applying patches in sequence. It was distributed, and elegant in its own way, but it didn't make the conceptual leap which Linus took with git. In contrast, the hash-based blob/tree/commit model of git was groundbreaking. The storage doesn't use deltas (except as an implementation detail--as an optimisation in pack files). Deltas are computed on demand. Operations on and synchronising between blob stores is simple and fast. That one change is what made git revolutionary. It opened the door for doing so much more with the version control system. Still, others took that step around the same time, and the git interface is not what one would call intuitive. But for various reasons it had the momentum and took the crown. It's not perfect, but it's still an absolutely superb tool.
- danbolt 6y ago
  I feel like GitHub made a lot of hacking around and software development a lot more seamless too. Before GitHub, the average state of software development seemed a bit more clunky to me.
  - qbasic_forever 6y ago
    Github made _Github style_ development seamless--i.e. centralized source control, slick web UI instead of CLI focus, pull requests instead of e-mailed patches. It's one of many different ways to build software though and it's a fallacy to say the entire field of software development didn't move forward until it existed. For someone who has only known Github style development it's true, but for many projects (including some of the largest in the world like the Linux kernel, all of Google's internal code, etc.) Github style development isn't necessary.
    - danbolt 6y ago
      > it's a fallacy to say the entire field of software development didn't move forward until it existed I mean, like, it kinda did in some ways? I feel like GitHub's semi-centralized web UI and pull requests empowered a lot of people to engage in software development online that wouldn't otherwise. I think if it didn't, we wouldn't see value in GitLab and Gittea providing GitHub's accessibility in a more decentralized way.
    - lmm 6y ago
      > it's a fallacy to say the entire field of software development didn't move forward until it existed A lot of software development got a lot better. Yes, software development was possible before GitHub, but it lowered the barrier to entry a lot.
- folkrav 6y ago
  > A much better UI Curious as how it's "better". I have in all honestly only ever used git.
  - ufo 6y ago
    One thing I prefer about Mercurial is that it doesn't have a separate staging area. To create a new commit in git you need to run `git add` followed by `git commit`. In Mercurial it's just `hg commit`. Furthermore, if you want to look at the diff in git sometimes it's `git diff` and sometimes you need to run `git diff --cached`. Now, I'm sure there are antsy git users in this forum ready to reply about how great the staging area is because of `git add -p`. I would note that you can also do those things in Hg if you want. For example, the `shelve` command in Hg is analogous to `git stash -p`. If you want to commit only part of the changes you can shelve away the things that you don't want to commit for now. One thing I like about this workflow compared to the staging area is that if you run your test suite, the code that is being tested in your working directory is the same one that will be commited.
    - acdha 6y ago
      > To create a new commit in git you need to run `git add` followed by `git commit`. Or `git commit -a` — and if you're making commits that frequently it'll be in your shell history anyway.
      - lmm 6y ago
        Except that if you added a new file then "git commit -a" will miss it out. Git's UI is full of little sharp edges like that. You get used to them, but it's just needlessly fiddly to start with.
        acdha 6y ago
        > Except that if you added a new file then "git commit -a" will miss it out. Exactly like Mercurial, you mean? Try it if you haven't in a while: you have to call “hg add” to add a new file or you'll get “nothing changed” when you run "hg commit". The reason why neither of them has a default “add everything in the current directory” mode is that this is how you end up with repositories containing temporary files, build artifacts, and secrets. This is not a good example to base ”much better UI” claims on.
- formerly_proven 6y ago
  Git is and always was very fast. Hg used to be much much slower, and still is.
  - lifthrasiir 6y ago
    Both were still very faster than the mainstream solution at the time that is Subversion. I don't think Git could achieve the domination comparable to today without Github for that reason.
  - gmueckl 6y ago
    Mercurial beats git in a fair bechmark on a large repository by now. As far as I know, no other DVCS received similar dedicated optimizations. (Microsoft worked around git by shimming a fake file system driver below the local repository to make it scale enouth to cover the Windows codebase. It's all Windows exclusive and not part of git, so it doesn't really count).
    - ammo1662 6y ago
      They asked to add it to Git, however they are rejected.
- dialamac 6y ago
  I mean git is wildly popular because of GitHub, and probably that was something to do with it in the Rails community... a community that if anything is culturally the opposite of the kernel dev community (or at least very different). I don’t think any kernel dev influence had to do with it, even though it’s often stated as a fact.
  - pdw 6y ago
    No, even at the time of GitHub's founding Git was already the clear winner. Think about it, why did GitHub feel safe launching with only Git support, while its competitors (Google Code, Bitbucket, SourceForge) had support for multiple VCSs?
    - simonw 6y ago
      Disagree. Git wasn't the clear winner when GitHub launched - and in fact the entire category of distributed version control was still proving itself. I remember the GitHub team investing huge amounts of effort into convincing people to use git and teaching them how to do it - one of the four co-founders (Scott) was dedicated to that effort full-time.
      - Person5478 6y ago
        git was the clear winner when github released.
        mikey_p 6y ago
        Not really, lots of folks were using mercurial with BitBucket which didn't support Git at the time. Bazaar and Launchpad were also pretty common. I remember at one point around 2009-2010 I was semi-regularly using CVS, Subversion, Mercurial, Bazaar and Git.
        Person5478 6y ago
        lots of people were using lots of things at that time, most were using git.
- acdha 6y ago
  Kind of — I started using Mercurial before using Git and found a number of things which were easier or only possible using Git. Using some of the plugins for things like rebase were the only time I've ever lost data in a version control system. By the time they had addressed some of those gaps, almost all of the projects I used had moved to GitHub, which seemed to be far more of a driver than Linux.
- eikenberry 6y ago
  If I remember correctly Mercurial also made some dubious decisions early on (which they later reversed) that hurt adoption, like no in-repo branches and no ability to change history.
  - oblio 6y ago
    > no ability to change history. This is a version control misfeature/bad practice. It's almost the single version control system that has it as part of its regular commands (though others allow it, generally as part of an admin set of permissions and usually with super clear warnings not to do it). And it's far from a reason why git won. Git won because it was written by Torvalds and every script kiddie dreams to be a Linux kernel hacker and because the Facebook for Code, Github, took off and it was based on git. Heck, I'd "accuse" you of rewriting history right now :-))
  - bsder 6y ago
    Mercurial also made the really good decision to support Windows long before git was even functional there. I've got clients who have been using Mercurial on Windows for more than 10 years now. They email bundles to each other and have no problems, whatsoever, and don't even notice git. One quote: "Why would I want to go back to a central repository that I have to be connected to? That's stupid." Most Windows users, sadly, are simply too backward to use anything that isn't tightly integrated into the Microsoft ecosystem. So, it never really helped Mercurial that much. GitHub, however, was what drove git. Unfortunately, Github is to source control as PowerPoint is to presentations. It works--but it's a dumbed-down default and nobody thinks about the fact that there are sometimes much better alternatives for your use case.
    - blt 6y ago
      Not sure I understand the analogy. What is PowerPoint a dumbed-down version of?
      - bsder 6y ago
        An actual textual report? Whiteboards? Overheads? Actual slides? Flip charts? Livecoding? Powerpoint is optimized for marketing and not much else. It exists because of two reasons: 1) Most people actively suck at presenting something. Forcing them to put their presentation in Powerpoint-standard forces some level of organization on them. 2) A lot of business presentation IS marketing--and Powerpoint is fine for that. The problem is that a lot of technical communication really doesn't fit into Powerpoint-standard (see: space-shuttle disasters for example). The problem is that now nobody knows how to do anything else and never even thinks about doing anything else.
- johannes1234321 6y ago
  Not only that, but GitHub came early and made the hosting easy. There was no similar offering for hg that early on.
  - qbasic_forever 6y ago
    Github wasn't created until 2008, and in those early days there were big limits on hosting (very limited number of repos per user, even public ones). The everything free, everything easy all you can eat buffet that you see on Github today is a much more recent change. Back in '05 almost everything OSS was on source forge and Google Code, both of which offered super easy hosting, discussions, etc.
    - johannes1234321 6y ago
      Sourceforge was already in demise, it was slow etc. when was it that they started adding malware? Don't remember ... i however remember Chris Wnastrath travelling to europe even for relatively small developer events and sponsoring the beer events. Quite a good marketing ...
  - tomjakubowski 6y ago
    Circa 2011, Bitbucket was Hg-only and pretty comparable to GitHub in repository hosting features at the time. Took a bit to dig up with Google their 2011 announcement that they're now also supporting Git. https://bitbucket.org/blog/bitbucket-now-rocks-git https://bitbucket.org/blog/bitbucket-now-rocks-git
- asiachick 6y ago
  git won because it's default workflow is better than hg's hg added stuff to match git's workflow but it isn't hg's default. The tutorials for hg all teach a decidedly inferior workflow to git. ps: did a 20 person year long project in hg first, next project was git. Not going back if I can help it.
fmakunbound 6y ago
Supposedly it has a nicer user interface. It's been ages since I've used it though and I am not sure if that's still true.
RcouF1uZ4gsC 6y ago
One advantage of mercurial is that it is less tied to a specific file format like git is. It is much easier to make a mercurial backend for a system which actually stores the code in a different way (for example a distributed data store).
- Mindless2112 6y ago
  ...or stores it in .git[1]. [1] https://www.mercurial-scm.org/wiki/GitExtension https://www.mercurial-scm.org/wiki/GitExtension
- klodolph 6y ago
  Isn’t this also possible with Git, at least for remotes? There are a number of different Git implementations besides the main one.
  - alexhutcheson 6y ago
    There are multiple implementations, but the contents of the .git directory are essentially the API, which tightly constrains how it can be implemented.
qbasic_forever 6y ago
Git didn't exist until Linus Torvalds sat down and hacked it out in a few weeks during 2005. I remember using SDL back in '99 to play with game development on Windows 98. So the short answer is, git wasn't even an idea in its creators head when SDL was around and thriving. IMHO when you see a design decision that seems odd to you, it's a good opportunity to investigate the entire context around that design, rather than pepper the devs/issues/comment threads/etc. with pointed questions, "Why did you do X when Y is now clearly better??".
- TonyTrapp 6y ago
  That doesn't really answer the question though as both Mercurial and Git were released in 2005.
- jrochkind1 6y ago
  However, Mercurial also didn't exist before 2005. https://en.wikipedia.org/wiki/Mercurial#History https://en.wikipedia.org/wiki/Mercurial#History i would guess you are right, though, that at the point SDL chose Mercurial (I don't know when), git hadn't achieved the market domination over mercurial it now has.
- mrpippy 6y ago
  SDL didn't use Mercurial until 2010. They used Subversion from 2006-2010 [1], and CVS before that [2]. A project on its 4th version control system! [1]: http://forums.libsdl.org/viewtopic.php?t=6047 http://forums.libsdl.org/viewtopic.php?t=6047 [2]: https://discourse.libsdl.org/t/sdl-in-subversion/13289 https://discourse.libsdl.org/t/sdl-in-subversion/13289
  - qbasic_forever 6y ago
    Again, I will restate what I said. Follow the context of the decisions (as you have already done) instead of demanding people explain it.
nijaru 6y ago
Mercurial is probably the most popular alternative, although if git wasn’t so ubiquitous, I would spend some time trying out fossil. edit: I can’t remember where, it was when I was researching fossil, but there are some good reads on why Linus created git and the history of VCSs.
d1zzy 6y ago
Seems to be popular at Facebook.[1] Where I work Mercurial has been an option for some time now (no Git unfortunately) and coming from Git I must say I really love how it does some of its things: - hg split: split a commit into as many different commits as you like using an interactive patch editor (you can fold/collapse hunks, can edit them textually, can select which lines of the hunk should be applied). It will automatically rebase all the commits on top of the commit being split, ofc - hg histedit: a sort of "git rebase -i" where you get a list of commits that you can manipulate by reordering them, merging, dropping - hg amend -i/commit -i: interactive commit or amending of a commit, it's using that awesome interactive patch editor I mentioned earlier to select what exactly gets committed/amended - same for "hg shelve -i" (a sort of "git stash") The closest thing in Git to that interactive patch editor was doing "git add -p" which is not as good. [1] https://engineering.fb.com/2014/01/07/core-data/scaling-mercurial-at-facebook/ https://engineering.fb.com/2014/01/07/core-data/scaling-merc...
- livvelupp 6y ago
  What's the other options besides hg if it ain't git?
  - Shorel 6y ago
    SQLite uses Fossil.
  - jen20 6y ago
    BitKeeper is one, Fossil is another. Then there are non-DVCS systems like Subversion, Perforce, VSTS etc.
  - pdw 6y ago
    darcs is still actively developed and it has a niche in the Haskell community. Ubuntu might still use Bazaar.
  - jimbob45 6y ago
    SVN still works well for our company.
  - 6y ago
ww520 6y ago
I've briefly used Mercurial and found it to be slower than Git in large repos. Mercurial has the concept of changeset (similar to Perforce) where the changeset is actually stored, while Git's "changeset" is computed as needed from two commits. Branch in Git is clear and straight forward, and is easily malleable, while Mercurial's branch is part of the version storage and cannot be changed or removed.
throwawayboise 6y ago
My VC history includes RCS, CVS, Visual Source Safe, then several years with Subversion. Moving from svn, the hg CLI was more intuitive. I still don't understand git at all, beyond the basic "clone, pull, add, commit, push" commands.
rileymat2 6y ago
I had tried both in thier infancy, and honestly prefered mercurial by quite a bit. But git had the momentum. One thing I liked, that most do not is they had both git style branches in the form of tags, but mercurial had "real" branches.
- tux1968 6y ago
  Git branches and tags were independent features from the very start. It's true that branches were not stored in a separate directory, but that really wouldn't add much. There were tools to check out a branch into a separate working directory on the filesystem. And it was always straightforward to store branches in separate full repos too.
  - rileymat2 6y ago
    That is fine, but what git does not have is branches baked into the history of the repo like HG or svn does. With git you can see this if you merge things back and forth then remove the branch names. There is no way to tell which commit was on was which branch. You just have the graph of commits. This is not true of HG, it is always there baked into the history.
    - tux1968 6y ago
      Yes, you're right. Although there are easy ways to mitigate this if it's actually important. Simply including the branch name in each commit message is simple enough, or disabling fast-forward merges so that each merge has its own separate commit and meta-data. Or even just not merging like that in the first place and using "feature branches" that are only ever merged back into the master branch, never the other way.
cpeterso 6y ago
Mozilla uses Mercurial for Firefox code because Mercurial had much better Windows support that git (at the time Mozilla was moving off CVS back in ~2007). Some Mozilla developers prefer git and use git plugins (cinnabar) to talk Mozilla's Mercurial servers. https://hg.mozilla.org/ https://hg.mozilla.org/
bsder 6y ago
Because I can explain Mercurial's mental model to anybody. And I have--from the CEO to the secretary--pretty much anybody can understand Mercurial. Git, not so much. The whole "staging" area is something that the vast majority of developers simply do not need and would be better off without. The UX of the commands is abysmal--commands that change what they do based upon whether the argument is a file or a directory? Are you insane? I could go on and on and on ... However, git has won. I keep my repos in Mercurial and transfer them out to Git for public consumption. :(
- wingerlang 6y ago
  What’s wrong with the staging area? It’s probably my number one most used feature. I tend to have a lot of changes in my working directory. Some are actual code, some are temporary fixes or comments. Maybe even another unrelated fix I threw in. Staging area allows me to pick the parts/files/lines I want for a particular commit.
  - bsder 6y ago
    That is far more state than most people are comfortable keeping track of. Most people have "working" and "committed" and that's almost more than they can deal with. Ever dealt with someone who has a specific breadcrumb trail for making changes to WordPress, for example? "Staging" is an extra set of steps to his breadcrumbs that can go wrong. The staging area is useful to a small number of people like you in return for complicating the life of everybody else.
    - wingerlang 6y ago
      Is it really that much state? For example, the thing I am working on right this moment have the following changes: 1. I changed my environment URL because I need to test on a specific one. 2. My actual feature changes, couple of files and a hundred lines changed. 3. A bunch of debug print messages, some are intertwined within the changes in 2, and some are in other places. I will stage most of things in 2, probably in multiple commits to group logically. Most of 1,3 will simply be discarded once I comment and test final version. 1, might stick around for the next features I work on. I can not believe this is too much state, nor can I believe this is not a fairly common workflow for developers? How would you do this without staging? Would you discard the temporary changes and commit, then possibly write them back manually? —- I appreciate the Wordpress example but I’m not familiar with it so it flies right over my head to be honest.
aayjaychan 6y ago
Changeset Evolution [1], which allows me to amend and rebase shared commits without co-workers hating me, even when they are building on top of the mutated commits. [1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution https://www.mercurial-scm.org/wiki/ChangesetEvolution combined with a large set of tools to tweak commits (i mostly use absorb, amend, split, fold, uncommit, pick), it is very nice to work with if you value a clean history. there is also the very powerful revset DSL for finding revisions and/or files.

by talhah 6y ago

I've never heard of mercurial until this post, I've been using git for version control and it does the job really well. To those who use mercurial over git, why?

jmercouris 6y ago

A much better UI. Git won because of the influence of the Linux kernel developers, that's all.

xyst 6y ago
The influence of a single linux kernel developer is the reason it's adoption is so high - Linus Torvalds.
- tux1968 6y ago
  That's much too simplistic. For instance Linus also denounces C++ and programmers don't fall into line behind him on that front. He is influential, but could not have caused the monumental shift in version control without producing a phenomenal tool to do the job. Git largely won on its overall merit, despite having some obvious UI warts.
- kbenson 6y ago
  Eh, that's a bit reductionist. Git was developed by Tovalds because BitKeeper had shortcomings he kept grating against, and it really needed to be a DVCS for kernel development. So he created something that fit the kernel development needs well, and it happened to also fit the needs of other companies as well. That it was free and open source was icing on the cake. That Torvalds created it just meant that there was already a wide audience of people willing to consider it and give it a fair shake initially. I'm sure it didn't hurt that Torvalds had many years of experience dealing with lots of the shortcomings of different version control systems and their shortcomings in what is probably one of the more extreme version control situations, and is also known for optimizing the hard parts of things. It was really the perfect storm for good open source software. A highly skilled developer with massive amounts of domain experience that is highly motivated to solve the problem. What you often get in those situations is something that is an obvious step up from the status quo, at least of free offerings, and often matching the paid offerings if they are more advanced. If it wasn't Torvalds, it just would have taken longer to take over.
  - rleigh 6y ago
    As you say, it can't be understated just how much of a conceptual leap git was. It wasn't developed in a vacuum. And there were several interesting distributed open source version control systems around at the time. After moving on from CVS and Subversion, I tried using Arch (tla) for a project. It was interesting, but still tied to the old way of thinking of version control as a series of deltas, both in its conceptual model and in its storage implementation. In fact, its storage was a tarball of a "base revision" plus a series of patches. Checking out a branch meant unpacking the tarball and applying patches in sequence. It was distributed, and elegant in its own way, but it didn't make the conceptual leap which Linus took with git. In contrast, the hash-based blob/tree/commit model of git was groundbreaking. The storage doesn't use deltas (except as an implementation detail--as an optimisation in pack files). Deltas are computed on demand. Operations on and synchronising between blob stores is simple and fast. That one change is what made git revolutionary. It opened the door for doing so much more with the version control system. Still, others took that step around the same time, and the git interface is not what one would call intuitive. But for various reasons it had the momentum and took the crown. It's not perfect, but it's still an absolutely superb tool.
danbolt 6y ago
I feel like GitHub made a lot of hacking around and software development a lot more seamless too. Before GitHub, the average state of software development seemed a bit more clunky to me.
- qbasic_forever 6y ago
  Github made _Github style_ development seamless--i.e. centralized source control, slick web UI instead of CLI focus, pull requests instead of e-mailed patches. It's one of many different ways to build software though and it's a fallacy to say the entire field of software development didn't move forward until it existed. For someone who has only known Github style development it's true, but for many projects (including some of the largest in the world like the Linux kernel, all of Google's internal code, etc.) Github style development isn't necessary.
  - danbolt 6y ago
    > it's a fallacy to say the entire field of software development didn't move forward until it existed I mean, like, it kinda did in some ways? I feel like GitHub's semi-centralized web UI and pull requests empowered a lot of people to engage in software development online that wouldn't otherwise. I think if it didn't, we wouldn't see value in GitLab and Gittea providing GitHub's accessibility in a more decentralized way.
  - lmm 6y ago
    > it's a fallacy to say the entire field of software development didn't move forward until it existed A lot of software development got a lot better. Yes, software development was possible before GitHub, but it lowered the barrier to entry a lot.
folkrav 6y ago
> A much better UI Curious as how it's "better". I have in all honestly only ever used git.
- ufo 6y ago
  One thing I prefer about Mercurial is that it doesn't have a separate staging area. To create a new commit in git you need to run `git add` followed by `git commit`. In Mercurial it's just `hg commit`. Furthermore, if you want to look at the diff in git sometimes it's `git diff` and sometimes you need to run `git diff --cached`. Now, I'm sure there are antsy git users in this forum ready to reply about how great the staging area is because of `git add -p`. I would note that you can also do those things in Hg if you want. For example, the `shelve` command in Hg is analogous to `git stash -p`. If you want to commit only part of the changes you can shelve away the things that you don't want to commit for now. One thing I like about this workflow compared to the staging area is that if you run your test suite, the code that is being tested in your working directory is the same one that will be commited.
  - acdha 6y ago
    > To create a new commit in git you need to run `git add` followed by `git commit`. Or `git commit -a` — and if you're making commits that frequently it'll be in your shell history anyway.
    - lmm 6y ago
      Except that if you added a new file then "git commit -a" will miss it out. Git's UI is full of little sharp edges like that. You get used to them, but it's just needlessly fiddly to start with.
      - acdha 6y ago
        > Except that if you added a new file then "git commit -a" will miss it out. Exactly like Mercurial, you mean? Try it if you haven't in a while: you have to call “hg add” to add a new file or you'll get “nothing changed” when you run "hg commit". The reason why neither of them has a default “add everything in the current directory” mode is that this is how you end up with repositories containing temporary files, build artifacts, and secrets. This is not a good example to base ”much better UI” claims on.
formerly_proven 6y ago
Git is and always was very fast. Hg used to be much much slower, and still is.
- lifthrasiir 6y ago
  Both were still very faster than the mainstream solution at the time that is Subversion. I don't think Git could achieve the domination comparable to today without Github for that reason.
- gmueckl 6y ago
  Mercurial beats git in a fair bechmark on a large repository by now. As far as I know, no other DVCS received similar dedicated optimizations. (Microsoft worked around git by shimming a fake file system driver below the local repository to make it scale enouth to cover the Windows codebase. It's all Windows exclusive and not part of git, so it doesn't really count).
  - ammo1662 6y ago
    They asked to add it to Git, however they are rejected.
dialamac 6y ago
I mean git is wildly popular because of GitHub, and probably that was something to do with it in the Rails community... a community that if anything is culturally the opposite of the kernel dev community (or at least very different). I don’t think any kernel dev influence had to do with it, even though it’s often stated as a fact.
- pdw 6y ago
  No, even at the time of GitHub's founding Git was already the clear winner. Think about it, why did GitHub feel safe launching with only Git support, while its competitors (Google Code, Bitbucket, SourceForge) had support for multiple VCSs?
  - simonw 6y ago
    Disagree. Git wasn't the clear winner when GitHub launched - and in fact the entire category of distributed version control was still proving itself. I remember the GitHub team investing huge amounts of effort into convincing people to use git and teaching them how to do it - one of the four co-founders (Scott) was dedicated to that effort full-time.
    - Person5478 6y ago
      git was the clear winner when github released.
      - mikey_p 6y ago
        Not really, lots of folks were using mercurial with BitBucket which didn't support Git at the time. Bazaar and Launchpad were also pretty common. I remember at one point around 2009-2010 I was semi-regularly using CVS, Subversion, Mercurial, Bazaar and Git.
        Person5478 6y ago
        lots of people were using lots of things at that time, most were using git.
acdha 6y ago
Kind of — I started using Mercurial before using Git and found a number of things which were easier or only possible using Git. Using some of the plugins for things like rebase were the only time I've ever lost data in a version control system. By the time they had addressed some of those gaps, almost all of the projects I used had moved to GitHub, which seemed to be far more of a driver than Linux.
eikenberry 6y ago
If I remember correctly Mercurial also made some dubious decisions early on (which they later reversed) that hurt adoption, like no in-repo branches and no ability to change history.
- oblio 6y ago
  > no ability to change history. This is a version control misfeature/bad practice. It's almost the single version control system that has it as part of its regular commands (though others allow it, generally as part of an admin set of permissions and usually with super clear warnings not to do it). And it's far from a reason why git won. Git won because it was written by Torvalds and every script kiddie dreams to be a Linux kernel hacker and because the Facebook for Code, Github, took off and it was based on git. Heck, I'd "accuse" you of rewriting history right now :-))
- bsder 6y ago
  Mercurial also made the really good decision to support Windows long before git was even functional there. I've got clients who have been using Mercurial on Windows for more than 10 years now. They email bundles to each other and have no problems, whatsoever, and don't even notice git. One quote: "Why would I want to go back to a central repository that I have to be connected to? That's stupid." Most Windows users, sadly, are simply too backward to use anything that isn't tightly integrated into the Microsoft ecosystem. So, it never really helped Mercurial that much. GitHub, however, was what drove git. Unfortunately, Github is to source control as PowerPoint is to presentations. It works--but it's a dumbed-down default and nobody thinks about the fact that there are sometimes much better alternatives for your use case.
  - blt 6y ago
    Not sure I understand the analogy. What is PowerPoint a dumbed-down version of?
    - bsder 6y ago
      An actual textual report? Whiteboards? Overheads? Actual slides? Flip charts? Livecoding? Powerpoint is optimized for marketing and not much else. It exists because of two reasons: 1) Most people actively suck at presenting something. Forcing them to put their presentation in Powerpoint-standard forces some level of organization on them. 2) A lot of business presentation IS marketing--and Powerpoint is fine for that. The problem is that a lot of technical communication really doesn't fit into Powerpoint-standard (see: space-shuttle disasters for example). The problem is that now nobody knows how to do anything else and never even thinks about doing anything else.
johannes1234321 6y ago
Not only that, but GitHub came early and made the hosting easy. There was no similar offering for hg that early on.
- qbasic_forever 6y ago
  Github wasn't created until 2008, and in those early days there were big limits on hosting (very limited number of repos per user, even public ones). The everything free, everything easy all you can eat buffet that you see on Github today is a much more recent change. Back in '05 almost everything OSS was on source forge and Google Code, both of which offered super easy hosting, discussions, etc.
  - johannes1234321 6y ago
    Sourceforge was already in demise, it was slow etc. when was it that they started adding malware? Don't remember ... i however remember Chris Wnastrath travelling to europe even for relatively small developer events and sponsoring the beer events. Quite a good marketing ...
- tomjakubowski 6y ago
  Circa 2011, Bitbucket was Hg-only and pretty comparable to GitHub in repository hosting features at the time. Took a bit to dig up with Google their 2011 announcement that they're now also supporting Git. https://bitbucket.org/blog/bitbucket-now-rocks-git https://bitbucket.org/blog/bitbucket-now-rocks-git
asiachick 6y ago
git won because it's default workflow is better than hg's hg added stuff to match git's workflow but it isn't hg's default. The tutorials for hg all teach a decidedly inferior workflow to git. ps: did a 20 person year long project in hg first, next project was git. Not going back if I can help it.

fmakunbound 6y ago

Supposedly it has a nicer user interface. It's been ages since I've used it though and I am not sure if that's still true.

RcouF1uZ4gsC 6y ago

One advantage of mercurial is that it is less tied to a specific file format like git is. It is much easier to make a mercurial backend for a system which actually stores the code in a different way (for example a distributed data store).

Mindless2112 6y ago
...or stores it in .git[1]. [1] https://www.mercurial-scm.org/wiki/GitExtension https://www.mercurial-scm.org/wiki/GitExtension
klodolph 6y ago
Isn’t this also possible with Git, at least for remotes? There are a number of different Git implementations besides the main one.
- alexhutcheson 6y ago
  There are multiple implementations, but the contents of the .git directory are essentially the API, which tightly constrains how it can be implemented.

qbasic_forever 6y ago

Git didn't exist until Linus Torvalds sat down and hacked it out in a few weeks during 2005. I remember using SDL back in '99 to play with game development on Windows 98. So the short answer is, git wasn't even an idea in its creators head when SDL was around and thriving. IMHO when you see a design decision that seems odd to you, it's a good opportunity to investigate the entire context around that design, rather than pepper the devs/issues/comment threads/etc. with pointed questions, "Why did you do X when Y is now clearly better??".

TonyTrapp 6y ago
That doesn't really answer the question though as both Mercurial and Git were released in 2005.
jrochkind1 6y ago
However, Mercurial also didn't exist before 2005. https://en.wikipedia.org/wiki/Mercurial#History https://en.wikipedia.org/wiki/Mercurial#History i would guess you are right, though, that at the point SDL chose Mercurial (I don't know when), git hadn't achieved the market domination over mercurial it now has.
mrpippy 6y ago
SDL didn't use Mercurial until 2010. They used Subversion from 2006-2010 [1], and CVS before that [2]. A project on its 4th version control system! [1]: http://forums.libsdl.org/viewtopic.php?t=6047 http://forums.libsdl.org/viewtopic.php?t=6047 [2]: https://discourse.libsdl.org/t/sdl-in-subversion/13289 https://discourse.libsdl.org/t/sdl-in-subversion/13289
- qbasic_forever 6y ago
  Again, I will restate what I said. Follow the context of the decisions (as you have already done) instead of demanding people explain it.

nijaru 6y ago

Mercurial is probably the most popular alternative, although if git wasn’t so ubiquitous, I would spend some time trying out fossil. edit: I can’t remember where, it was when I was researching fossil, but there are some good reads on why Linus created git and the history of VCSs.

d1zzy 6y ago

Seems to be popular at Facebook.[1] Where I work Mercurial has been an option for some time now (no Git unfortunately) and coming from Git I must say I really love how it does some of its things: - hg split: split a commit into as many different commits as you like using an interactive patch editor (you can fold/collapse hunks, can edit them textually, can select which lines of the hunk should be applied). It will automatically rebase all the commits on top of the commit being split, ofc - hg histedit: a sort of "git rebase -i" where you get a list of commits that you can manipulate by reordering them, merging, dropping - hg amend -i/commit -i: interactive commit or amending of a commit, it's using that awesome interactive patch editor I mentioned earlier to select what exactly gets committed/amended - same for "hg shelve -i" (a sort of "git stash") The closest thing in Git to that interactive patch editor was doing "git add -p" which is not as good. [1] https://engineering.fb.com/2014/01/07/core-data/scaling-mercurial-at-facebook/ https://engineering.fb.com/2014/01/07/core-data/scaling-merc...

livvelupp 6y ago
What's the other options besides hg if it ain't git?
- Shorel 6y ago
  SQLite uses Fossil.
- jen20 6y ago
  BitKeeper is one, Fossil is another. Then there are non-DVCS systems like Subversion, Perforce, VSTS etc.
- pdw 6y ago
  darcs is still actively developed and it has a niche in the Haskell community. Ubuntu might still use Bazaar.
- jimbob45 6y ago
  SVN still works well for our company.
- 6y ago

ww520 6y ago

I've briefly used Mercurial and found it to be slower than Git in large repos. Mercurial has the concept of changeset (similar to Perforce) where the changeset is actually stored, while Git's "changeset" is computed as needed from two commits. Branch in Git is clear and straight forward, and is easily malleable, while Mercurial's branch is part of the version storage and cannot be changed or removed.

throwawayboise 6y ago

My VC history includes RCS, CVS, Visual Source Safe, then several years with Subversion. Moving from svn, the hg CLI was more intuitive. I still don't understand git at all, beyond the basic "clone, pull, add, commit, push" commands.

rileymat2 6y ago

I had tried both in thier infancy, and honestly prefered mercurial by quite a bit. But git had the momentum. One thing I liked, that most do not is they had both git style branches in the form of tags, but mercurial had "real" branches.

tux1968 6y ago
Git branches and tags were independent features from the very start. It's true that branches were not stored in a separate directory, but that really wouldn't add much. There were tools to check out a branch into a separate working directory on the filesystem. And it was always straightforward to store branches in separate full repos too.
- rileymat2 6y ago
  That is fine, but what git does not have is branches baked into the history of the repo like HG or svn does. With git you can see this if you merge things back and forth then remove the branch names. There is no way to tell which commit was on was which branch. You just have the graph of commits. This is not true of HG, it is always there baked into the history.
  - tux1968 6y ago
    Yes, you're right. Although there are easy ways to mitigate this if it's actually important. Simply including the branch name in each commit message is simple enough, or disabling fast-forward merges so that each merge has its own separate commit and meta-data. Or even just not merging like that in the first place and using "feature branches" that are only ever merged back into the master branch, never the other way.

cpeterso 6y ago

Mozilla uses Mercurial for Firefox code because Mercurial had much better Windows support that git (at the time Mozilla was moving off CVS back in ~2007). Some Mozilla developers prefer git and use git plugins (cinnabar) to talk Mozilla's Mercurial servers. https://hg.mozilla.org/ https://hg.mozilla.org/

bsder 6y ago

Because I can explain Mercurial's mental model to anybody. And I have--from the CEO to the secretary--pretty much anybody can understand Mercurial. Git, not so much. The whole "staging" area is something that the vast majority of developers simply do not need and would be better off without. The UX of the commands is abysmal--commands that change what they do based upon whether the argument is a file or a directory? Are you insane? I could go on and on and on ... However, git has won. I keep my repos in Mercurial and transfer them out to Git for public consumption. :(

wingerlang 6y ago
What’s wrong with the staging area? It’s probably my number one most used feature. I tend to have a lot of changes in my working directory. Some are actual code, some are temporary fixes or comments. Maybe even another unrelated fix I threw in. Staging area allows me to pick the parts/files/lines I want for a particular commit.
- bsder 6y ago
  That is far more state than most people are comfortable keeping track of. Most people have "working" and "committed" and that's almost more than they can deal with. Ever dealt with someone who has a specific breadcrumb trail for making changes to WordPress, for example? "Staging" is an extra set of steps to his breadcrumbs that can go wrong. The staging area is useful to a small number of people like you in return for complicating the life of everybody else.
  - wingerlang 6y ago
    Is it really that much state? For example, the thing I am working on right this moment have the following changes: 1. I changed my environment URL because I need to test on a specific one. 2. My actual feature changes, couple of files and a hundred lines changed. 3. A bunch of debug print messages, some are intertwined within the changes in 2, and some are in other places. I will stage most of things in 2, probably in multiple commits to group logically. Most of 1,3 will simply be discarded once I comment and test final version. 1, might stick around for the next features I work on. I can not believe this is too much state, nor can I believe this is not a fairly common workflow for developers? How would you do this without staging? Would you discard the temporary changes and commit, then possibly write them back manually? —- I appreciate the Wordpress example but I’m not familiar with it so it flies right over my head to be honest.

aayjaychan 6y ago

Changeset Evolution [1], which allows me to amend and rebase shared commits without co-workers hating me, even when they are building on top of the mutated commits. [1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution https://www.mercurial-scm.org/wiki/ChangesetEvolution combined with a large set of tools to tweak commits (i mostly use absorb, amend, split, fold, uncommit, pick), it is very nice to work with if you value a clean history. there is also the very powerful revset DSL for finding revisions and/or files.