3 ms·

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.
    - Kranar 3y ago
      It's true that it's been a decade since I used SVN so I could be misremebering, I just remember branching and merging being a much larger pain than in git.
      - mangodrunk 3y ago
        I know what you mean, when git was gaining popularity I do remember people saying that branching being better/easier in git. I do think it was overstated back then and just not true. I haven’t used svn in years as well, but I think it was mostly due to the hype than any objective merit.
      - Izkata 3y ago
        Branches were made by copying the directory tree, and svn doesn't have local commits so it always went straight to the server. I think svn also originally didn't have merging, or at the very least it was such a bad experience svnmerge.py was created and really common to use. Even once it got good it was mostly the equivalent of using git cherry-pick to pull commits across branches, though it did get a special "reintegrate" mode for diffing a branch and applying that back to trunk (and I remember there being something about it being possible to accidentally undo commits if you weren't fully up to date when running it...?) Edit: I remember now, all changes on trunk had to be merged into your branch first, or reintegrate would interpret it as if your branch undid those commits and remove the changes from trunk. It basically made trunk look exactly the same as the branch did at that moment.
    - ynik 3y ago
      Making an svn branch and scrapping it, indeed never was a big deal. Making an svn branch and merging it, now that was a huge issue. "svn merge" sucked compared to "git merge". For the project I was managing back in 2007 I started using git-svn, because importing Subversion commits into git, using "git merge", and then exporting commits back to the subversion server, was faster and worked better than "svn merge" did (back in 2007).

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.
  - Kranar 3y ago
    It's true that it's been a decade since I used SVN so I could be misremebering, I just remember branching and merging being a much larger pain than in git.
    - mangodrunk 3y ago
      I know what you mean, when git was gaining popularity I do remember people saying that branching being better/easier in git. I do think it was overstated back then and just not true. I haven’t used svn in years as well, but I think it was mostly due to the hype than any objective merit.
    - Izkata 3y ago
      Branches were made by copying the directory tree, and svn doesn't have local commits so it always went straight to the server. I think svn also originally didn't have merging, or at the very least it was such a bad experience svnmerge.py was created and really common to use. Even once it got good it was mostly the equivalent of using git cherry-pick to pull commits across branches, though it did get a special "reintegrate" mode for diffing a branch and applying that back to trunk (and I remember there being something about it being possible to accidentally undo commits if you weren't fully up to date when running it...?) Edit: I remember now, all changes on trunk had to be merged into your branch first, or reintegrate would interpret it as if your branch undid those commits and remove the changes from trunk. It basically made trunk look exactly the same as the branch did at that moment.
  - ynik 3y ago
    Making an svn branch and scrapping it, indeed never was a big deal. Making an svn branch and merging it, now that was a huge issue. "svn merge" sucked compared to "git merge". For the project I was managing back in 2007 I started using git-svn, because importing Subversion commits into git, using "git merge", and then exporting commits back to the subversion server, was faster and worked better than "svn merge" did (back in 2007).