3 ms·

Unpopular opinion: This is how git rose to where it is today. If people were less blinded by celebrity status, they'd see that Linus' lack of exposure to paradi

Unpopular opinion: This is how git rose to where it is today. If people were less blinded by celebrity status, they'd see that Linus' lack of exposure to paradigms beyond C such as OOP or FP (due to deliberate disdain; his loss) meant that C pointers were the primary abstraction on which he built git, and that it suffers greatly because of this. Not to mention that good UX is a rare skill among developers in general. See https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/ Mercurial should have won. And Plastic SCM is awesome, designed conceptually from the ground up to build on lessons learned from git (and by an Associate Professor in CS). In fact, the whole concept of DVCSs is ridiculous in 99% of corporate contexts where you can't use your laptop / desktop at home without logging in into the VPN. Why do we even need distributed version control in such a setting? Subversion is perfectly enough and even non-developer users can actually understand and use Subversion effectively. See https://svnvsgit.com/ https://svnvsgit.com/ Mind you, I'm not a blind hater: I love that Linus did well in life. I'd be thrilled if his net worth was a billion instead of just $150 million. Surely, he contributed much more than that.

theamk 6y ago
Can we stop with the conspiracy theories? Git rose where it was today for a multitude reasons, most of them technical: it is very fast, rebase is well supported, if it breaks it’s easy to fix and so on. (Yes, some of these are fixed now, but it is too late) I mean, many people had the exposure to bit git and hg at some point in their life - especially the kind of people who make decision which vcs to use. Celebrity endorsement may be good to convince me to try something, but it cannot convince one to use something over alternatives, if they had enough experience with both.
- dannyw 6y ago
  It also doesn’t really matter. Git is good enough. Hg is good enough.
- mikekchar 6y ago
  Speed was definitely a big deal when git first came into being. However, as far as I remember, the main thing that made git popular was actually Github. Before Github, various souce repository sites were awful (and in the case of what SourceForge became, more than awful).
  - taeric 6y ago
    I recall that the git-svn bridge had me hooked on git long before github. Also made it braindead simple to migrate an svn shop. We looked at hg. I also dabbled in a few others. bzr, I believe was a popular one. As said upstream. There are plenty of reasons that git "won." Most of them did seem technical. But, I could see things going many ways. For the most part, source control is not a problem most people think they have. Just look at how terrible the data science folks are? And management is stuck in whatever MS is doing in Word nowadays.
    - fomine3 6y ago
      "Plaintext and VCS solve all problems" is not very practical for everyone other than programmers.
      - taeric 6y ago
        The other fields also have a terrible time recreating anything. So... I kind of feel that they are making the poor choice here. In particular, I have yet to see a successful collaboration that wasn't ridiculously ephemeral in data science or document creation, that wasn't backed by a much nicer format. (Where, ephemeral means that after it is done, it is referenced as PDF, but not directly anymore. Which, to be fair, is the majority of documents that exist in the world.)
mappu 6y ago
I spent easily 10 000 hours using Mercurial over nearly 10 years. I was, and still am, a huge Hg fan. I switched to Git quite late (some time in 2018) and converted all projects, both home+work, cold turkey. I recently revisited an old Hg project. It was really nostalgic. Hg is easier to use and TortoiseHg is the best GUI for SCM bar none. But Git is simpler. The simplicity is a mind-opener. Git deserved to win. When you want to do something in Hg that's not built-in - even something like rebase - all the 30+ included extensions are all marked as "EXPERIMENTAL" and you can only safely interact with the data model by writing a custom Python 2 script. With Git you can go into the .git directory and delete a refs file. Filter-branch is a first-class feature. A few basic concepts underpin more functionality. There are genuine multiple implementations. This is radical transparency. Originally I thought I would have missed having draft phases, embedded branch names, and ordinal commit numbers. But in practice I don't miss these at all. And in retrospect these all actively work against code-sharing in general, and the pull-request model specifically with its working revisions. Git is inherently more social-capable and will always have a stronger network effect. Hg does not have separate author + committer. With Git you can stage individual lines, not just hunks. This alone should be reason to use Git over Hg (oh, you can enable the optional crecord extension and do everything from the CLI? that's not Hg's famed ease-of-use). I once started to develop a Gogs/Gitea clone for Hg. For compatibility it had to communicate by IPC with a standalone Python process, then I hit a roadblock because the wireproto was undocumented for bundles. Hg developers were also not enthusiastic about my proposal to switch from full+diff storage to chunk storage. I do miss some things. A central .hgtags file would definitely resolve some tag conflicts and issues with coworkers re-pushing deleted tags.
- vijucat 6y ago
  Thanks, very good points.
xwolfi 6y ago
Having used subversion and git in big teams, I can tell you the single fact branches are free in git changes the way teams interact and is worth every learning curve or design flaw in git. From spending half a day per branch copy, to releasing only a few times per year because branches are expensive, to never changing more than the minimum because can't branch-test a feature fast, to days of offline CI because bad merge on only dev branch, to keeping 3 copies of the entire repo to do backports because not easy to shift branch... SVN never again.
toyg 6y ago
I can’t upvote you because I agree on half of what you say and disagree with the other half. Yes, git “won” largely because it was “what the Linux guys are using” (and because github was better than bitbucket and other alternatives). It’s concepts can be painful to work with. No, DVCS should not be ditched - the simplicity of repointing, rehosting, and working offline, that dvcs systems give us, should never be rolled back (and screw repo corruptions in svn and other crap). Just because a lot of people don’t rely on these features every day, it doesn’t mean they are not hugely beneficial to the ecosystem at large.
benibela 6y ago
I use Mercurial for almost everything The hg command line options are far more sane than git. And TortoiseHg is the best gui ever But I might switch eventually, when even bitbucket is dropping hg support. And many linux distributions stopped including a working tortoisehg.
fragmede 6y ago
It's impossible to separate out the celebrity of Linus the person, and the celebrity of the Linux kernel he created. Git rose to where it is because of its success in being used for managing distributed Linux kernel development, rather than adulation of Linus. That it's not a great fit for things that aren't Linux kernel development isn't exactly a surprise. In a world where "DVCSs is ridiculous in 99% of corporate contexts where you can't use your laptop / desktop at home without logging [sic] into the VPN", why (and what) should Mercurial, a popular DVCS, have "won"? (I don't mean in Mercurial vs Git) DVCS isn't ridiculous. Especially in corporate contexts over a flakey VPN (like, say, if there were a global remote work experiment going on). Cheap local branching is an indispensable feature. So much so that if you're forced to use SVN, you can still get local branching via SVK or by using `git-svn`. SVN is still the right tool in a lot of places (anywhere there are binaries in play) though the overhead of being actively fluent in multiple VCSs at once isn't free.

theamk 6y ago

Can we stop with the conspiracy theories? Git rose where it was today for a multitude reasons, most of them technical: it is very fast, rebase is well supported, if it breaks it’s easy to fix and so on. (Yes, some of these are fixed now, but it is too late) I mean, many people had the exposure to bit git and hg at some point in their life - especially the kind of people who make decision which vcs to use. Celebrity endorsement may be good to convince me to try something, but it cannot convince one to use something over alternatives, if they had enough experience with both.

dannyw 6y ago
It also doesn’t really matter. Git is good enough. Hg is good enough.
mikekchar 6y ago
Speed was definitely a big deal when git first came into being. However, as far as I remember, the main thing that made git popular was actually Github. Before Github, various souce repository sites were awful (and in the case of what SourceForge became, more than awful).
- taeric 6y ago
  I recall that the git-svn bridge had me hooked on git long before github. Also made it braindead simple to migrate an svn shop. We looked at hg. I also dabbled in a few others. bzr, I believe was a popular one. As said upstream. There are plenty of reasons that git "won." Most of them did seem technical. But, I could see things going many ways. For the most part, source control is not a problem most people think they have. Just look at how terrible the data science folks are? And management is stuck in whatever MS is doing in Word nowadays.
  - fomine3 6y ago
    "Plaintext and VCS solve all problems" is not very practical for everyone other than programmers.
    - taeric 6y ago
      The other fields also have a terrible time recreating anything. So... I kind of feel that they are making the poor choice here. In particular, I have yet to see a successful collaboration that wasn't ridiculously ephemeral in data science or document creation, that wasn't backed by a much nicer format. (Where, ephemeral means that after it is done, it is referenced as PDF, but not directly anymore. Which, to be fair, is the majority of documents that exist in the world.)

mappu 6y ago

I spent easily 10 000 hours using Mercurial over nearly 10 years. I was, and still am, a huge Hg fan. I switched to Git quite late (some time in 2018) and converted all projects, both home+work, cold turkey. I recently revisited an old Hg project. It was really nostalgic. Hg is easier to use and TortoiseHg is the best GUI for SCM bar none. But Git is simpler. The simplicity is a mind-opener. Git deserved to win. When you want to do something in Hg that's not built-in - even something like rebase - all the 30+ included extensions are all marked as "EXPERIMENTAL" and you can only safely interact with the data model by writing a custom Python 2 script. With Git you can go into the .git directory and delete a refs file. Filter-branch is a first-class feature. A few basic concepts underpin more functionality. There are genuine multiple implementations. This is radical transparency. Originally I thought I would have missed having draft phases, embedded branch names, and ordinal commit numbers. But in practice I don't miss these at all. And in retrospect these all actively work against code-sharing in general, and the pull-request model specifically with its working revisions. Git is inherently more social-capable and will always have a stronger network effect. Hg does not have separate author + committer. With Git you can stage individual lines, not just hunks. This alone should be reason to use Git over Hg (oh, you can enable the optional crecord extension and do everything from the CLI? that's not Hg's famed ease-of-use). I once started to develop a Gogs/Gitea clone for Hg. For compatibility it had to communicate by IPC with a standalone Python process, then I hit a roadblock because the wireproto was undocumented for bundles. Hg developers were also not enthusiastic about my proposal to switch from full+diff storage to chunk storage. I do miss some things. A central .hgtags file would definitely resolve some tag conflicts and issues with coworkers re-pushing deleted tags.

vijucat 6y ago
Thanks, very good points.

xwolfi 6y ago

Having used subversion and git in big teams, I can tell you the single fact branches are free in git changes the way teams interact and is worth every learning curve or design flaw in git. From spending half a day per branch copy, to releasing only a few times per year because branches are expensive, to never changing more than the minimum because can't branch-test a feature fast, to days of offline CI because bad merge on only dev branch, to keeping 3 copies of the entire repo to do backports because not easy to shift branch... SVN never again.

toyg 6y ago

I can’t upvote you because I agree on half of what you say and disagree with the other half. Yes, git “won” largely because it was “what the Linux guys are using” (and because github was better than bitbucket and other alternatives). It’s concepts can be painful to work with. No, DVCS should not be ditched - the simplicity of repointing, rehosting, and working offline, that dvcs systems give us, should never be rolled back (and screw repo corruptions in svn and other crap). Just because a lot of people don’t rely on these features every day, it doesn’t mean they are not hugely beneficial to the ecosystem at large.

benibela 6y ago

I use Mercurial for almost everything The hg command line options are far more sane than git. And TortoiseHg is the best gui ever But I might switch eventually, when even bitbucket is dropping hg support. And many linux distributions stopped including a working tortoisehg.

fragmede 6y ago

It's impossible to separate out the celebrity of Linus the person, and the celebrity of the Linux kernel he created. Git rose to where it is because of its success in being used for managing distributed Linux kernel development, rather than adulation of Linus. That it's not a great fit for things that aren't Linux kernel development isn't exactly a surprise. In a world where "DVCSs is ridiculous in 99% of corporate contexts where you can't use your laptop / desktop at home without logging [sic] into the VPN", why (and what) should Mercurial, a popular DVCS, have "won"? (I don't mean in Mercurial vs Git) DVCS isn't ridiculous. Especially in corporate contexts over a flakey VPN (like, say, if there were a global remote work experiment going on). Cheap local branching is an indispensable feature. So much so that if you're forced to use SVN, you can still get local branching via SVK or by using `git-svn`. SVN is still the right tool in a lot of places (anywhere there are binaries in play) though the overhead of being actively fluent in multiple VCSs at once isn't free.