9 ms·

I started my distributed version control journey when SVN was still king of the hill and git and mercurial were both tiny challengers. I actually picked mercur

I started my distributed version control journey when SVN was still king of the hill and git and mercurial were both tiny challengers. I actually picked mercurial first. I found the interface more intuitive, especially coming from svn. The problem was that everyday commands were just dog slow -- 5, 10 seconds on every single interaction. It felt like wading through molasses, contrast to git, which was effectively instantaneous on small repos and git on my large repo was still multiples faster than hg on a small repo. Also, IIRC hg didn't have a "git stash" equivalent. I chose git on its merits and didn't look back. A few years later (2010 ish?) I met a mercurial evangelist who said things had changed on the performance front, but I checked and they hadn't. I'll give hg the benefit of the doubt that it eventually got better, but I have serious doubts about your accusation that git's success had to do with marketing. I gave hg a more than even chance and it lost, fair and square, on technical merit, as weighted according to my everyday use cases.

dragonsh 7y ago
I started with CVS then moved to svn. From there moved to bazaar (bzr), from there moved to git and at last used mercurial and settled on it. I still keep an active look at fossil SCM. In my earlier team at fortune 100 firm, most developers use Windows with svn. We tried git and it did not work well due to UI and windows support. They were able to pick up UI easily and were quickly productive in mercurial. It worked pretty good on all 3 platform Windows, Mac and Linux. I am talking of time when GitHub was not that popular in corporate world. Performance was never an issue. Also at that time mercurial followed philosophy of being explicit and every merge needs to be explicit and committed with immutable history. So can see the evolution of code along with the mistakes made. I believe the success of git is due to GitHub and for many it's synonymous.
- throw0101a 7y ago
  > I started with CVS then moved to svn. When I was your age we used RCS and SCCS, in the snow, up hill, in both directions. :) Seriously, I have no doubt git has an awesome on-disk format, but whenever I use the git(1) command I want to slit my wrists. I'm sure if a developer uses it many times a day it's possible to get used to it, but as a sysadmin that only uses it sporadically, I basically do: * git clone * vi repo/some/file/blah * git add/commit/push * rm -rf repo/
  - deleted 7y ago
    [deleted]
  - seanmcdirmid 7y ago
    Some people on the other side of the Unix/Microsoft tracks started out on sourcesafe.... shudder
    - jsgo 7y ago
      raises hand dunno, I like git better, but at the time it did what our small team needed. Granted, we always ran into issues with one of us having a file locked that someone else needed, but onboarding was a breeze. I'm glad I use git now, but Sourcesafe was an okay introductory source control solution.
  - mey 7y ago
    Order of my exposure to SCM Shared windows mount Visual Source Safe CVS SVN Perforce ClearCase Git Team Foundation Server Of those I still use Git and SVN. Aside from the shared network drive, VSS and ClearCase are in a dead heat for the worst SCM I have been exposed to.
    - keithnoizu 7y ago
      I feel blessed to have started with SVN and Source Depot (msft) and only come across CVS and Perforce on rare occasions.
      - robaato 7y ago
        Source Depot == Perforce
      - hyperrail 7y ago
        Source Depot is very similar to Perforce since sd started as a p4 fork. Incidentally, I remember one person at Microsoft who claimed to be involved in the decision to adopt sd circa 1999 saying that Microsoft has the right to turn sd into a product if it so chooses. (He/she was responding to contrary claims made on an internal email mailing list which was very widely read, so I assume if he/she was misremembering or lying he/she would have been called out.) Though ultimately MSFT made VSTS/TFS version control instead, which has striking resemblances in concepts to sd/p4.
- WorldMaker 7y ago
  I started with CVS in HS on a couple SourceForge projects, but skipped svn for the same reasons I used CVS sparingly: setting up servers was too much effort, (especially for non-open source stuff), especially on Windows. Instead of svn I fell hard in love for darcs in college (after the usual college tale of losing source files the day before a project was due in a stupid unix tool mishap with a command line that was one letter off from what it should have been). Watching hg and git grow up and compete as a darcs user was fascinating. Neither hg nor git had the elegance of the darcs UI (and arguably never will due to disparities in the underlying distributed code model), but it was clear from very early on that both hg and git were beating darcs on performance for large, active repositories. (Which was never a problem for a college student working on teams of maybe 1 to 3, but obviously a hard recommendation for the real world.) I experimented some with hg at the time because it had good Windows support, but had no reason to switch from darcs in college. My first couple of jobs after college had me spending a lot of time in TFVC, and that eventually that lead to a much greater appreciation of git (and pushing teams to migrate from TFVC to git), and by that point TFS had already starting supporting git side-by-side TFVC, though ironically those same teams pushed hard for GitHub Enterprise. (Which does seem to underscore that git and GitHub really were so co-beneficial.) By that point a lot of what hg had done right the git team was starting to pick up. At the very least, we should remember hg for pushing git to be better. (As one example, someone else pointed to `git stash` as something that they didn't think hg had, but as I recall `mercurial queues` [MQ] was one of the earliest hg plugins, and MQ influenced the designs of both `git rebase` and `git stash`, and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.)
  - BeetleB 7y ago
    >and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ. I believe those have been deprecated in favor of the evolve extension. Mercurial is my goto for version control. However, in my experience, the information on the ideal tools/extensions is very scattered. The Mercurial book is 10 years old! For example, few mercurial users make use of branches for throwaway work - they use bookmarks. But how is a new user supposed to know that?
- tasssko 7y ago
  Git was successful before github. I’d say Github was successful because of git!
  - kjeetgill 7y ago
    I was going to write this exact comment. I'm sure the "marketing" of "Linus Made!" and "used for the Kernel!" did git some favors, but git is technically superior in my experience, despite UI short comings. I'm sure it's changed now, but the lack of cheap fast branching was jarring. I think many UI fetishists forget: Good UI helps begginer adoption but has to be incredibly way better to drive any readoption. But professionals will often have to suck it up and use a shitty UI if it means solving a technical shortcoming better.
  - benibela 7y ago
    And perhaps because there is no good offline ui for git So you end up using github as ui, even if you do not want to use a webpage
jstewartmobile 7y ago
I've been using hg since 2012 on a few decent sized repositories, and it has never been anything other than immediate.
- jschwartzi 7y ago
  I've got a 1.2 GB repository and it's pretty fast for that once you set Watchman up to cache tree changes. It's dog slow without that little added step though, mostly because there are a ton of small files.
deleted 7y ago
[deleted]
hyperrail 7y ago
Git was once fast for my use too. Then I returned to Microsoft to work on building Windows. Even after 2.5 years of improvement,[1] "git is slow" is still one of the most common complaints about the Windows engineering system. On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value. We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do. [1] since https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
- Arnavion 7y ago
  >several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value. That one at least is fixed now, by having an option to disable it. https://github.com/git/git/blob/v2.23.0/Documentation/config/status.txt#L15-L18 https://github.com/git/git/blob/v2.23.0/Documentation/config...
  - hyperrail 7y ago
    That git setting is for `git status`, but I think `git checkout branch` still doesn't have a comparable option either on the command line or in a git configuration file. The closest you can get is to turn off all output with `git checkout -q`.
    - Arnavion 7y ago
      Oh yes, I just tested it out and you're right. Bummer.
- Someone1234 7y ago
  Definitely sounds like a problem. Do you think an alternative source control solution would handle that situation better? At some point huge with a large number of small files takes its toll. It would be interesting for someone inside Microsoft to write a blog describing why Git works well for the Linux Kernel but not for the Windows Kernel. They cannot be that different from a layout perspective, can they?
Grue3 7y ago
>I'll give hg the benefit of the doubt that it eventually got better It did not. We had a giant hg monorepo at Yandex, and even mere "hg id" took ages (and required net access to source repository for some reason). The plan was to eventually switch to it from SVN, not sure if they eventually did because I left the company.

dragonsh 7y ago

I started with CVS then moved to svn. From there moved to bazaar (bzr), from there moved to git and at last used mercurial and settled on it. I still keep an active look at fossil SCM. In my earlier team at fortune 100 firm, most developers use Windows with svn. We tried git and it did not work well due to UI and windows support. They were able to pick up UI easily and were quickly productive in mercurial. It worked pretty good on all 3 platform Windows, Mac and Linux. I am talking of time when GitHub was not that popular in corporate world. Performance was never an issue. Also at that time mercurial followed philosophy of being explicit and every merge needs to be explicit and committed with immutable history. So can see the evolution of code along with the mistakes made. I believe the success of git is due to GitHub and for many it's synonymous.

throw0101a 7y ago
> I started with CVS then moved to svn. When I was your age we used RCS and SCCS, in the snow, up hill, in both directions. :) Seriously, I have no doubt git has an awesome on-disk format, but whenever I use the git(1) command I want to slit my wrists. I'm sure if a developer uses it many times a day it's possible to get used to it, but as a sysadmin that only uses it sporadically, I basically do: * git clone * vi repo/some/file/blah * git add/commit/push * rm -rf repo/
- deleted 7y ago
  [deleted]
- seanmcdirmid 7y ago
  Some people on the other side of the Unix/Microsoft tracks started out on sourcesafe.... shudder
  - jsgo 7y ago
    raises hand dunno, I like git better, but at the time it did what our small team needed. Granted, we always ran into issues with one of us having a file locked that someone else needed, but onboarding was a breeze. I'm glad I use git now, but Sourcesafe was an okay introductory source control solution.
- mey 7y ago
  Order of my exposure to SCM Shared windows mount Visual Source Safe CVS SVN Perforce ClearCase Git Team Foundation Server Of those I still use Git and SVN. Aside from the shared network drive, VSS and ClearCase are in a dead heat for the worst SCM I have been exposed to.
  - keithnoizu 7y ago
    I feel blessed to have started with SVN and Source Depot (msft) and only come across CVS and Perforce on rare occasions.
    - robaato 7y ago
      Source Depot == Perforce
    - hyperrail 7y ago
      Source Depot is very similar to Perforce since sd started as a p4 fork. Incidentally, I remember one person at Microsoft who claimed to be involved in the decision to adopt sd circa 1999 saying that Microsoft has the right to turn sd into a product if it so chooses. (He/she was responding to contrary claims made on an internal email mailing list which was very widely read, so I assume if he/she was misremembering or lying he/she would have been called out.) Though ultimately MSFT made VSTS/TFS version control instead, which has striking resemblances in concepts to sd/p4.
WorldMaker 7y ago
I started with CVS in HS on a couple SourceForge projects, but skipped svn for the same reasons I used CVS sparingly: setting up servers was too much effort, (especially for non-open source stuff), especially on Windows. Instead of svn I fell hard in love for darcs in college (after the usual college tale of losing source files the day before a project was due in a stupid unix tool mishap with a command line that was one letter off from what it should have been). Watching hg and git grow up and compete as a darcs user was fascinating. Neither hg nor git had the elegance of the darcs UI (and arguably never will due to disparities in the underlying distributed code model), but it was clear from very early on that both hg and git were beating darcs on performance for large, active repositories. (Which was never a problem for a college student working on teams of maybe 1 to 3, but obviously a hard recommendation for the real world.) I experimented some with hg at the time because it had good Windows support, but had no reason to switch from darcs in college. My first couple of jobs after college had me spending a lot of time in TFVC, and that eventually that lead to a much greater appreciation of git (and pushing teams to migrate from TFVC to git), and by that point TFS had already starting supporting git side-by-side TFVC, though ironically those same teams pushed hard for GitHub Enterprise. (Which does seem to underscore that git and GitHub really were so co-beneficial.) By that point a lot of what hg had done right the git team was starting to pick up. At the very least, we should remember hg for pushing git to be better. (As one example, someone else pointed to `git stash` as something that they didn't think hg had, but as I recall `mercurial queues` [MQ] was one of the earliest hg plugins, and MQ influenced the designs of both `git rebase` and `git stash`, and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.)
- BeetleB 7y ago
  >and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ. I believe those have been deprecated in favor of the evolve extension. Mercurial is my goto for version control. However, in my experience, the information on the ideal tools/extensions is very scattered. The Mercurial book is 10 years old! For example, few mercurial users make use of branches for throwaway work - they use bookmarks. But how is a new user supposed to know that?
tasssko 7y ago
Git was successful before github. I’d say Github was successful because of git!
- kjeetgill 7y ago
  I was going to write this exact comment. I'm sure the "marketing" of "Linus Made!" and "used for the Kernel!" did git some favors, but git is technically superior in my experience, despite UI short comings. I'm sure it's changed now, but the lack of cheap fast branching was jarring. I think many UI fetishists forget: Good UI helps begginer adoption but has to be incredibly way better to drive any readoption. But professionals will often have to suck it up and use a shitty UI if it means solving a technical shortcoming better.
- benibela 7y ago
  And perhaps because there is no good offline ui for git So you end up using github as ui, even if you do not want to use a webpage

jstewartmobile 7y ago

I've been using hg since 2012 on a few decent sized repositories, and it has never been anything other than immediate.

jschwartzi 7y ago
I've got a 1.2 GB repository and it's pretty fast for that once you set Watchman up to cache tree changes. It's dog slow without that little added step though, mostly because there are a ton of small files.

deleted 7y ago

[deleted]

hyperrail 7y ago

Git was once fast for my use too. Then I returned to Microsoft to work on building Windows. Even after 2.5 years of improvement,[1] "git is slow" is still one of the most common complaints about the Windows engineering system. On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value. We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do. [1] since https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...

Arnavion 7y ago
>several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value. That one at least is fixed now, by having an option to disable it. https://github.com/git/git/blob/v2.23.0/Documentation/config/status.txt#L15-L18 https://github.com/git/git/blob/v2.23.0/Documentation/config...
- hyperrail 7y ago
  That git setting is for `git status`, but I think `git checkout branch` still doesn't have a comparable option either on the command line or in a git configuration file. The closest you can get is to turn off all output with `git checkout -q`.
  - Arnavion 7y ago
    Oh yes, I just tested it out and you're right. Bummer.
Someone1234 7y ago
Definitely sounds like a problem. Do you think an alternative source control solution would handle that situation better? At some point huge with a large number of small files takes its toll. It would be interesting for someone inside Microsoft to write a blog describing why Git works well for the Linux Kernel but not for the Windows Kernel. They cannot be that different from a layout perspective, can they?

Grue3 7y ago

>I'll give hg the benefit of the doubt that it eventually got better It did not. We had a giant hg monorepo at Yandex, and even mere "hg id" took ages (and required net access to source repository for some reason). The plan was to eventually switch to it from SVN, not sure if they eventually did because I left the company.