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.
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.
git was deliberately designed around the "known fast" things in Linux.
One of those is that path name lookup for certain file attributes is dirt cheap because of the dentry cache.
Since Windows doesn't have an equivalent, git is going to be slower there.
Hopefully the Microsoft people working on this will find ways to make git on Windows faster, since even with a much smaller repo (LibreOffice), git is somewhat painful on Windows.
my takeaway of the demo I saw on WSL2 at the Microsoft conference was basically several hours of engineers salivating over how much faster git was on wsl2
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`.
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?
I believe the difference is that the Linux kernel itself is not that big a project. Windows is a lot more than just a kernel; it’s more akin to having the source code for an entire Linux distribution in one repo.
Yes, most of the components and files in a default Windows installation are built from sources in the main Windows OS git repo.
Some parts of Windows have split out into their own repos and CI build and test pipelines, but splitting is a process that takes people's time and has pros and cons, especially when changes in the main OS repo are needed to give the separated components a complete, coherent API surface.
The Windows tree is unlike the Linux tree in that the Windows tree is the entirety of Windows, not just the kernel. Not having to check out the entire tree is why GVFS was made.
I read an article a while back about why git is slower on windows than on linux (probably linked from HN, but I can't find it just now) and the TLDR is that it's because the windows filesystem (not just NTFS, but everything around it) has many customization points, and for that reason git will always be slower on windows regardless of the particular underlying FS (as in, adding windows support for, say, ext4 wouldn't fix the problem).
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.
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:
I'm in the same camp of rm -rf'ing (and when I were a lad we did all our computing on relays...). A fun game to play when you have spare time is to Google for how to do some random thing with git then pour up a cup of coffee and read through the 17 contradictory answers on just one SO page...
Throw in SCCS, on SCO Unixware, and Darcs, and you match my exposure too, mostly. Now I remember what an abomination VSS was - with the mandatory locking behaviour.
It wasn't mandatory, actually. It was possible to turn off the locking. But that was like entering a whole new world of pain. So most people didn't dare turn it off.
They called it "multiple checkout", and the manual strongly recommended you do not turn it on.
The software had issues with corruption due to operations not being atomic.
I remember when you basically had to yell "Committing!" and "Done committing!" to the whole room. Woe be unto those companies that tried to use VSS or CVS with more than a roomful of developers.
I could live with the locking or the corrupted repos if it was half decent at just sharing code, but daily we had problems where someone would check in code, VSS would say it was checked in but the person updating would get stale versions. Sometimes if you looked at the server version it be be correct but not what you would receive on a fresh checkout.
It was literally less functional than copying to a shared drive. Of course management and other developers refused to believe that OSS solutions were better, MS ecosystem developers were an extremely insular group.
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.
Interesting. It wasn't a bad solution at the time, being able to pass around commits was nice and more straight forward than the patch mechanism on svn. Git and Mercurial were significantly superior solutions though.
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.
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.)
>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?
Neat. I was unaware of the evolve extension. It's interesting to see things continued to progress since I last read anything on the subject.
All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations, on top of how scattered the documentation is. It is interesting, perhaps how hg has a better UI, but git has always had arguably more consistent documentation.
(Similar too, both hg and git are built as sets of "plugins" to the core CLI but hg requires much more explicit installation and git just bundled a lot of them directly together and implicitly runs anything that even looks close [any script in the PATH that fits git-command may be run for git command], making it less clear which hg commands to use despite the better general UI, and easier to get started in git with a smorgasbord of commands.)
I somewhat remember the Named Branches versus Bookmarks discussion/confusion thing from the last time I attempted to use hg. It sounds unfortunate that it still doesn't seem very well documented or well explained this many years later.
>All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations
I believe it is bug free, and fit for real world usage, and has been for years. If you read the details, the issue is there is a chance for performance degradation, and they consider that as "backward incompatible".
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.
>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.
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.
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.