8 ms·

It's been about a decade since git "won" the version control war due to the (yet another) unjustified tech hype wave, and we're still having difficulties with w

It's been about a decade since git "won" the version control war due to the (yet another) unjustified tech hype wave, and we're still having difficulties with what should be trivial tasks. I remember reading a comment by Linus Torvalds being surprised that people started using git directly rather than putting a friendlier layer on top. If it was capable of introspection, the industry would admit it made a mistake by going with git and switch to another VCS instead, rather than wasting huge amounts of time on a tool whose only job is to save text.

Lutger 3y ago
> whose only job is to save text I don't see git as a tool to save text, its for coordinating changes on the same 'text' by multiple people, and doing so quite precisely and reliably, without blocking anyone's path forward. Try that with word. It could be better, yes. But I'm always surprised by the hate git gets. Its an amazing tool and miles ahead of the tools we created for non-developers (word, google docs, etc). Maybe its because I'm old enough to remember when subversion was king.
- tharkun__ 3y ago
  This. Git is miles ahead of anything else. Is is entirely intuitive to everyone? No. Did developers always have trouble with version control and merging? Yes. In my experience most devs don't grok version control, period. It does not matter if it's SVN, CVS, RCS, Visual Source Safe, Clearcase, Perforce, you name it. Or now git.
  - rebolek 3y ago
    If you think Git is miles ahead of anything else, you probably haven't really used anything else. I don't think that Git sucks, it's usable. But there are better alternatives.
    - tharkun__ 3y ago
      Do tell. Your post is missing examples of better alternatives and why they are better. FWIW, yes I have used others, maybe not the ones you have. I have used some of the ones mentioned in my list of examples, though not all but also others not mentioned.
    - gilcot 3y ago
      Alternatives like: fossil[1], mercurial[2], pijul[3], veracity[4]. [1] https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... [2] https://www.mercurial-scm.org/ https://www.mercurial-scm.org/ [3] https://stackoverflow.blog/2023/05/23/for-those-who-just-dont-git-it-ep-573/ https://stackoverflow.blog/2023/05/23/for-those-who-just-don... [4] http://veracity-scm.com/ http://veracity-scm.com/
      - tharkun__ 3y ago
        I've only used one of those. Mercurial: I was not impressed. Yes it sort of works but if you know git, you just miss the fact that everything (tags and branches) in git is just a label. At least that's what I missed in the two years I had to use mercurial. Fossil: Haven't used it but the main advantages touted in the doc you linked to aren't advantages to me. I.e. the only thing I'd want from it are the actual file versioning parts. And then I read things like You can say "fossil all sync" on a laptop prior to taking it off the network hosting those repos, as before going on a trip. It doesn't matter if those repos are private and restricted to your company network or public Internet-hosted repos, you get synced up with everything you need while off-network. Err, yeah, I `git pull` my repo(s) before going on a trip and it doesn't matter if they're private and restricted to my company network and I am synced up with everything I need while off-network. So? Pijul: Sounds interesting from a first read but I'd take some time to actually read about it and try it out for real. Veracity: `(C) 2010-2014 SourceGear`. I don't want to be that guy, but: really?
        gilcot 3y ago
        Yes, `git pull` and you have your repo synced. But guess why people are using Github (or alternative forges)? They want issues and maybe documentation/wiki etc. And Fossil has all those features too and that's the "all" you sync. ;)
- Tomis02 3y ago
  > whose only job is to save text It's a hyperbole, a figure of speech used to make a point. I'm pretty sure everyone on HN knows what git is used for. > Maybe its because I'm old enough to remember when subversion was king. I used SVN for more than a year. Why would you compare git with SVN rather than other DVCS like Mercurial?
  - Lutger 3y ago
    > It's a hyperbole, a figure of speech used to make a point. I'm pretty sure everyone on HN knows what git is used for. I know. The hyperbole makes it sound as if gits job is actually quite simple and we could easily have a better system. But I disagree with that, I don't believe it is simple. Most other tools have and are failing still at this. > Why would you compare it with SVN rather than other DVCS like Mercurial? Because SVN ruled the world back then and that is what I and many other devs used. Many of us went from SVN to Git without even knowing what Mercurial was. That explains why I was (eventually) so in awe of git, had I gone from Mercurial to Git I might have lamented the loss of a more friendly system. I do actually remember doing the odd thing with mercurial and it being much smoother to work with, but then git was already becoming the dominant player.
    - Tomis02 3y ago
      > Many of us went from SVN to Git without even knowing what Mercurial was. Yeah I know, that's the problem. In other words, many of us decided git is the best because many of us didn't know any better. But it's been more than a decade, surely that's enough time to reevaluate one's position.
      - pwagland 3y ago
        But, be honest, git was better than mercurial as well. And the reason that it's better is that the support is universal (now). Even back when the battle was being actively waged between git and hg, the popularity of git made it a better choice for pretty much everyone.
- scottlamb 3y ago
  > Maybe its because I'm old enough to remember when subversion was king. Heh. I'm old enough to remember when CVS was king. Subversion was a huge improvement. Git was too. I have every reason to believe further huge improvements are possible. They might have to be gargantuan though to overcome inertia by now.
  - Ygg2 3y ago
    Just look at what sucks in Git. Large file handling and submodule/subtree.
    - funcDropShadow 3y ago
      submodule and subtree are difficult concepts that look easy at a first glance. That is not the fault of the implementation.
      - Ygg2 3y ago
        For record that's something SVN had. It's difficult in distributed setting.
  - NikkiA 3y ago
    And CVS was a huge step up from RCS and SCCS synced via sneakernet, well, it seemed huge at the time, now it seems like a tiny step compared to everything that came after.
jordigh 3y ago
In 2013, it was far from clear that git would win. There was still a sizable amount of users of darcs, Mercurial, svn, and even cvs. Many of the tools of that era would have plugins to support all of them. I wish we still had that, because git monoculture also means that anything that replaces git first has to reimplement git. This means that just like ASCII or scroll lock buttons, we're stuck with git mostly forever.
PH95VuimJjqBqy 3y ago
> unjustified tech hype wave git won for good reasons, it's clearly better than what came before it. It may be popular to shit on it now (similarly for jquery), but when it arrived on the scene it was clearly an improvement.
- gilcot 3y ago
  It won because it was used by Linux kernel first and second because gave it an interface to ease things. https://stackoverflow.blog/2023/01/09/beyond-git-the-other-version-control-systems-developers-use/ https://stackoverflow.blog/2023/01/09/beyond-git-the-other-v...
  - 0cf8612b2e1e 3y ago
    Plus the gorilla that is GitHub. Which was significantly better than the contemporary alternatives of SourceForge, BitBucket, or Google Code. In a parallel universe, had there been a HgHub (with same strong initial iteration as GitHub), I have no doubt that mercurial would have won.
  - ynik 3y ago
    The way I got into git was: I was working on a project using Subversion and wanted to be able to work on train rides (and internet connectivity on trains wasn't a thing back in 2007). Initially I tried SVK, but I found that git-svn actually worked better. In fact, it worked so well, I stopped using "svn merge" (which took 5+ minutes on our repository for every merge), and started using "git merge" with git-svn instead (which reduced the merge time to <3s, and even the extra git<->svn sync overhead cost only 30s or so). As a bonus, git also reported fewer "merge conflicts" (svn at the time had issues repeatedly merging from a branch to trunk). So when I ended up picking a DVCS for another project, git was the natural choice since I already knew it. I imagine there are a lot of developers who started out on SVN and took a similar route to learning git, so having a high-quality Subversion bridge turned out to be one of the critical features on the road to adoption. This advantage in adoption then snowballed via forges like GitHub.
  - gilcot 3y ago
regularjack 3y ago
Git won because it's better than Subversion, and because of GitHub.
- iamcreasy 3y ago
  I think the parent comment is trying to say that not all project requires feature rich tool like Git. I also suspect for many many project subversion is good enough.
- mangodrunk 3y ago
  How is git better than svn?
  - Ygg2 3y ago
    You don't need to lock tree to deal with merges, you can edit your own commits (e.g. scrub someone due to GDPR from history), works offline, relatively fast.
    - metabagel 3y ago
      The trade off is complexity. Subversion was very easy to use. You could work around it’s limitations, if your project wasn’t the Linux kernel.
  - Kranar 3y ago
    Just being able to create a local branch, experiment with some changes and then either scrap the whole thing or merge them back is a big productivity boost. I feel like with SVN making a branch was like a "big deal" and something you had to think about, whereas in git making a branch is cheap and just part of a normal work flow.
    - mangodrunk 3y ago
      Making an svn branch is not a big deal and you can certainly create a branch in svn and scrap it. It seems that the git hype of 10 or so years ago was very effective.
failingslowly 3y ago
Hard agree. Weekly, I witness co-workers confused about git, I see posts online asking for help, I see articles like the one here once again trying in vain to explain something that should be simple. In all my time coding, I don't remember anyone wasting hours trying to undo some mess they'd made in SVN, TFVC, Perforce, etc. Tools exist to make our lives easier. If they can't do that, they don't deserve our time.
- jstimpfle 3y ago
  It is a true power tool. It does need an initial investment to get over the hump but I would never go back to SVN. It doesn't take a huge amount of time to really learn the basic concepts and then maybe the 10 most used commands (I suggest using git cat-file -p to navigate a repo and history manually). There is a wealth of functionality and an inconsistent terminology, but you can quickly look that up when you actually need it.
  - metabagel 3y ago
    I feel like some people are better at the context switch between the project they are working on and git. I am not good at that context switch.
- jtolmar 3y ago
  I remember seeing people blow up their SVN projects fairly often, usually from trying to move folders around without telling it. Though I don't remember those turning into three developers hovering over one computer the way that git errors so often do.
- Izkata 3y ago
  Confusion over svn was standard operating procedure over here for years before teams started using git regularly. I think I'm still the only one here that really understands how svn merge and svnmerge.py work, and have had to detangle plenty of messes over the years. We'd kind of standardized on trunk-based development because everyone was afraid of even attempting merges.
- fijiaarone 3y ago
retpoline__ 3y ago
>It's been about a decade since git "won" the version control war due to the (yet another) unjustified tech hype wave Hah, I've recently wrote a post about similar issue - why we may be locked with git. >So what's the issue here? I'm worried that just because GitHub is so good, then unless they decouple from git as letters management engine and allow any/other, then we will be locked with git. https://trolololo.xyz/github https://trolololo.xyz/github https://news.ycombinator.com/item?id=38098109 https://news.ycombinator.com/item?id=38098109

Lutger 3y ago

> whose only job is to save text I don't see git as a tool to save text, its for coordinating changes on the same 'text' by multiple people, and doing so quite precisely and reliably, without blocking anyone's path forward. Try that with word. It could be better, yes. But I'm always surprised by the hate git gets. Its an amazing tool and miles ahead of the tools we created for non-developers (word, google docs, etc). Maybe its because I'm old enough to remember when subversion was king.

tharkun__ 3y ago
This. Git is miles ahead of anything else. Is is entirely intuitive to everyone? No. Did developers always have trouble with version control and merging? Yes. In my experience most devs don't grok version control, period. It does not matter if it's SVN, CVS, RCS, Visual Source Safe, Clearcase, Perforce, you name it. Or now git.
- rebolek 3y ago
  If you think Git is miles ahead of anything else, you probably haven't really used anything else. I don't think that Git sucks, it's usable. But there are better alternatives.
  - tharkun__ 3y ago
    Do tell. Your post is missing examples of better alternatives and why they are better. FWIW, yes I have used others, maybe not the ones you have. I have used some of the ones mentioned in my list of examples, though not all but also others not mentioned.
  - gilcot 3y ago
    Alternatives like: fossil[1], mercurial[2], pijul[3], veracity[4]. [1] https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... [2] https://www.mercurial-scm.org/ https://www.mercurial-scm.org/ [3] https://stackoverflow.blog/2023/05/23/for-those-who-just-dont-git-it-ep-573/ https://stackoverflow.blog/2023/05/23/for-those-who-just-don... [4] http://veracity-scm.com/ http://veracity-scm.com/
    - tharkun__ 3y ago
      I've only used one of those. Mercurial: I was not impressed. Yes it sort of works but if you know git, you just miss the fact that everything (tags and branches) in git is just a label. At least that's what I missed in the two years I had to use mercurial. Fossil: Haven't used it but the main advantages touted in the doc you linked to aren't advantages to me. I.e. the only thing I'd want from it are the actual file versioning parts. And then I read things like You can say "fossil all sync" on a laptop prior to taking it off the network hosting those repos, as before going on a trip. It doesn't matter if those repos are private and restricted to your company network or public Internet-hosted repos, you get synced up with everything you need while off-network. Err, yeah, I `git pull` my repo(s) before going on a trip and it doesn't matter if they're private and restricted to my company network and I am synced up with everything I need while off-network. So? Pijul: Sounds interesting from a first read but I'd take some time to actually read about it and try it out for real. Veracity: `(C) 2010-2014 SourceGear`. I don't want to be that guy, but: really?
      - gilcot 3y ago
        Yes, `git pull` and you have your repo synced. But guess why people are using Github (or alternative forges)? They want issues and maybe documentation/wiki etc. And Fossil has all those features too and that's the "all" you sync. ;)
Tomis02 3y ago
> whose only job is to save text It's a hyperbole, a figure of speech used to make a point. I'm pretty sure everyone on HN knows what git is used for. > Maybe its because I'm old enough to remember when subversion was king. I used SVN for more than a year. Why would you compare git with SVN rather than other DVCS like Mercurial?
- Lutger 3y ago
  > It's a hyperbole, a figure of speech used to make a point. I'm pretty sure everyone on HN knows what git is used for. I know. The hyperbole makes it sound as if gits job is actually quite simple and we could easily have a better system. But I disagree with that, I don't believe it is simple. Most other tools have and are failing still at this. > Why would you compare it with SVN rather than other DVCS like Mercurial? Because SVN ruled the world back then and that is what I and many other devs used. Many of us went from SVN to Git without even knowing what Mercurial was. That explains why I was (eventually) so in awe of git, had I gone from Mercurial to Git I might have lamented the loss of a more friendly system. I do actually remember doing the odd thing with mercurial and it being much smoother to work with, but then git was already becoming the dominant player.
  - Tomis02 3y ago
    > Many of us went from SVN to Git without even knowing what Mercurial was. Yeah I know, that's the problem. In other words, many of us decided git is the best because many of us didn't know any better. But it's been more than a decade, surely that's enough time to reevaluate one's position.
    - pwagland 3y ago
      But, be honest, git was better than mercurial as well. And the reason that it's better is that the support is universal (now). Even back when the battle was being actively waged between git and hg, the popularity of git made it a better choice for pretty much everyone.
scottlamb 3y ago
> Maybe its because I'm old enough to remember when subversion was king. Heh. I'm old enough to remember when CVS was king. Subversion was a huge improvement. Git was too. I have every reason to believe further huge improvements are possible. They might have to be gargantuan though to overcome inertia by now.
- Ygg2 3y ago
  Just look at what sucks in Git. Large file handling and submodule/subtree.
  - funcDropShadow 3y ago
    submodule and subtree are difficult concepts that look easy at a first glance. That is not the fault of the implementation.
    - Ygg2 3y ago
      For record that's something SVN had. It's difficult in distributed setting.
- NikkiA 3y ago
  And CVS was a huge step up from RCS and SCCS synced via sneakernet, well, it seemed huge at the time, now it seems like a tiny step compared to everything that came after.

jordigh 3y ago

In 2013, it was far from clear that git would win. There was still a sizable amount of users of darcs, Mercurial, svn, and even cvs. Many of the tools of that era would have plugins to support all of them. I wish we still had that, because git monoculture also means that anything that replaces git first has to reimplement git. This means that just like ASCII or scroll lock buttons, we're stuck with git mostly forever.

PH95VuimJjqBqy 3y ago

> unjustified tech hype wave git won for good reasons, it's clearly better than what came before it. It may be popular to shit on it now (similarly for jquery), but when it arrived on the scene it was clearly an improvement.

gilcot 3y ago
It won because it was used by Linux kernel first and second because gave it an interface to ease things. https://stackoverflow.blog/2023/01/09/beyond-git-the-other-version-control-systems-developers-use/ https://stackoverflow.blog/2023/01/09/beyond-git-the-other-v...
- 0cf8612b2e1e 3y ago
  Plus the gorilla that is GitHub. Which was significantly better than the contemporary alternatives of SourceForge, BitBucket, or Google Code. In a parallel universe, had there been a HgHub (with same strong initial iteration as GitHub), I have no doubt that mercurial would have won.
- ynik 3y ago
  The way I got into git was: I was working on a project using Subversion and wanted to be able to work on train rides (and internet connectivity on trains wasn't a thing back in 2007). Initially I tried SVK, but I found that git-svn actually worked better. In fact, it worked so well, I stopped using "svn merge" (which took 5+ minutes on our repository for every merge), and started using "git merge" with git-svn instead (which reduced the merge time to <3s, and even the extra git<->svn sync overhead cost only 30s or so). As a bonus, git also reported fewer "merge conflicts" (svn at the time had issues repeatedly merging from a branch to trunk). So when I ended up picking a DVCS for another project, git was the natural choice since I already knew it. I imagine there are a lot of developers who started out on SVN and took a similar route to learning git, so having a high-quality Subversion bridge turned out to be one of the critical features on the road to adoption. This advantage in adoption then snowballed via forges like GitHub.
- gilcot 3y ago

regularjack 3y ago

Git won because it's better than Subversion, and because of GitHub.

iamcreasy 3y ago
I think the parent comment is trying to say that not all project requires feature rich tool like Git. I also suspect for many many project subversion is good enough.
mangodrunk 3y ago
How is git better than svn?
- Ygg2 3y ago
  You don't need to lock tree to deal with merges, you can edit your own commits (e.g. scrub someone due to GDPR from history), works offline, relatively fast.
  - metabagel 3y ago
    The trade off is complexity. Subversion was very easy to use. You could work around it’s limitations, if your project wasn’t the Linux kernel.
- Kranar 3y ago
  Just being able to create a local branch, experiment with some changes and then either scrap the whole thing or merge them back is a big productivity boost. I feel like with SVN making a branch was like a "big deal" and something you had to think about, whereas in git making a branch is cheap and just part of a normal work flow.
  - mangodrunk 3y ago
    Making an svn branch is not a big deal and you can certainly create a branch in svn and scrap it. It seems that the git hype of 10 or so years ago was very effective.

failingslowly 3y ago

Hard agree. Weekly, I witness co-workers confused about git, I see posts online asking for help, I see articles like the one here once again trying in vain to explain something that should be simple. In all my time coding, I don't remember anyone wasting hours trying to undo some mess they'd made in SVN, TFVC, Perforce, etc. Tools exist to make our lives easier. If they can't do that, they don't deserve our time.

jstimpfle 3y ago
It is a true power tool. It does need an initial investment to get over the hump but I would never go back to SVN. It doesn't take a huge amount of time to really learn the basic concepts and then maybe the 10 most used commands (I suggest using git cat-file -p to navigate a repo and history manually). There is a wealth of functionality and an inconsistent terminology, but you can quickly look that up when you actually need it.
- metabagel 3y ago
  I feel like some people are better at the context switch between the project they are working on and git. I am not good at that context switch.
jtolmar 3y ago
I remember seeing people blow up their SVN projects fairly often, usually from trying to move folders around without telling it. Though I don't remember those turning into three developers hovering over one computer the way that git errors so often do.
Izkata 3y ago
Confusion over svn was standard operating procedure over here for years before teams started using git regularly. I think I'm still the only one here that really understands how svn merge and svnmerge.py work, and have had to detangle plenty of messes over the years. We'd kind of standardized on trunk-based development because everyone was afraid of even attempting merges.
fijiaarone 3y ago

retpoline__ 3y ago

>It's been about a decade since git "won" the version control war due to the (yet another) unjustified tech hype wave Hah, I've recently wrote a post about similar issue - why we may be locked with git. >So what's the issue here? I'm worried that just because GitHub is so good, then unless they decouple from git as letters management engine and allow any/other, then we will be locked with git. https://trolololo.xyz/github https://trolololo.xyz/github https://news.ycombinator.com/item?id=38098109 https://news.ycombinator.com/item?id=38098109