5 ms·

Why opting for Git was a natural choice

13 points by mataug 13y ago

mataug 13y ago
The gist: The technicalities of moving away from SVN was never a problem for us, It was more of a workflow issue. I think this should be the real reason anyone should consider moving their codebase from SVN to GIT.
sircausticsoda 13y ago
Git sucks. It ruins my process. SVN has great integration with eclipse .
- roryokane 13y ago
  It would be more accurate to phrase that not as “Git sucks”, but as “the EGit plugin sucks”, or, if you must generalize, “Git’s ecosystem sucks”.
  - mataug 13y ago
    I would agree, There is nothing that can beat the Git-cli at least for now.
    - chrismonsanto 13y ago
      magit (https://github.com/magit/magit https://github.com/magit/magit) is unequivocally better than the Git CLI if you use Emacs.
  - davvid 13y ago
    I would disagree with the generalization that "Git's ecosystem sucks", though ;-) Many tools have Git support these days, and supplemental tools around Git are plentiful and quite mature. The Git community is friendly and helpful, especially around the mailing list and IRC.
- andyhmltn 13y ago
  Why? I personally don't use Eclipse but I'm sure there is a tool out there to provide similar functionality.
  - mataug 13y ago
    Intellij and other IDEs from jetBrains have pretty good GIT integration that works quite well and is similar to the GIT-cli
  - vivekmadurai 13y ago
    If I want to move to GIT, then I should use all the advantages of GIT, I couldn't find single GIT client/plugin that directly supports all the advanced features in GIT including Egit, intellij and others.
    - mataug 13y ago
      I doubt if any tool can ever support all the advanced features of GIT like its plumbing commands. Even a feature like rebase is which is fairly understandable on the CLI, becomes difficult to use on a GUI
    - andyhmltn 13y ago
      I would assume that being able to work offline and not depend on a central repo is enough of a benefit anyhow
      - mataug 13y ago
        I don't this is really a killer feature in this age of always connected devices.
        andyhmltn 13y ago
        If you've ever tried to get a decent connection on a train through England on a particular network, you'd disagree :)
millstone 13y ago
I think this article does not do the svn workflow justice. Svn was designed with the inherent assumption that the context of a developer within any single codebase would be linear This may be how the engineers in question used svn, but that's certainly not how svn was designed! Creating a branch in Subversion is not difficult or expensive. It's natural for each engineer on a team to have a separate svn directory containing "private" branches. If engineers are committing unstable code to the trunk, they're doing it wrong. Git branching is also cheap and quick, unlike svn in which a branching creating a new copy of code. Git also preserves history when branching, unlike Svn. Subversion uses copy-on-write when creating a branch, so it is not expensive. Subversion also records the branch event in the file's history. It sounds like the team had a flawed understanding of svn, and was using a terrible workflow. The benefits of the switch are not due to git, but to investing actual time learning a scm tool. That same time invested into learning svn would have paid equal dividends.
- taspeotis 13y ago
  > Subversion uses copy-on-write when creating a branch, so it is not expensive It doesn't matter what the server does, it's relatively slow on the client to either switch to or checkout a branch.
  - raimue 13y ago
    On the plus side, you can have multiple local branches side-by-side with svn easily, which is much easier to work with for beginners as they can just view and compare the trees in the filesystem. With git, such a setup requires more understanding on how to make a local clone instead of fetching the full history from the server multiple times.
    - Dylan16807 13y ago
      Fetching the full history in git is often less data than a checkout in svn. Also you could just copy the folder. Edit: git-new-workdir looks like it makes things convenient.
  - 13y ago
tehwalrus 13y ago
The way I handled branching in SVN was to have several checkouts of the same trunk, and run "svn update" to fast-forward before committing (once my patch had passed code review.) Hard drives are cheap, brain cells expensive! (note, this model works fine when you have a big company machine sat in an office on gigabit LAN to the SVN server - break any of the assumptions there, and SVN quickly deteriorates. I'm not saying git isn't better, just than SVN isn't that bad where I encountered it.)
- Peaker 13y ago
  Hard drives are slow. Copying a huge working tree to make a small branch makes no sense.
  - tehwalrus 13y ago
    I would just permanently maintain 4 or 5 checkouts of active projects, and rename the containing directories for branch names. I know git is better, I'm just saying SVN can be used in a similar way, if less efficiently.
deleted 13y ago
[deleted]
- Peaker 13y ago
  The ability to reorder commits, split them, squash them, etc in an interactive Rebase is unparalleled in svn, which necessarily means lower quality history. Working with higher quality history when merging, cherry picking, reverting, etc is much more productive. Understanding code with high quality history is easier too.

13 points by mataug 13y ago

The gist: The technicalities of moving away from SVN was never a problem for us, It was more of a workflow issue. I think this should be the real reason anyone should consider moving their codebase from SVN to GIT.

sircausticsoda 13y ago

Git sucks. It ruins my process. SVN has great integration with eclipse .

roryokane 13y ago
It would be more accurate to phrase that not as “Git sucks”, but as “the EGit plugin sucks”, or, if you must generalize, “Git’s ecosystem sucks”.
- mataug 13y ago
  I would agree, There is nothing that can beat the Git-cli at least for now.
  - chrismonsanto 13y ago
    magit (https://github.com/magit/magit https://github.com/magit/magit) is unequivocally better than the Git CLI if you use Emacs.
- davvid 13y ago
  I would disagree with the generalization that "Git's ecosystem sucks", though ;-) Many tools have Git support these days, and supplemental tools around Git are plentiful and quite mature. The Git community is friendly and helpful, especially around the mailing list and IRC.
andyhmltn 13y ago
Why? I personally don't use Eclipse but I'm sure there is a tool out there to provide similar functionality.
- mataug 13y ago
  Intellij and other IDEs from jetBrains have pretty good GIT integration that works quite well and is similar to the GIT-cli
- vivekmadurai 13y ago
  If I want to move to GIT, then I should use all the advantages of GIT, I couldn't find single GIT client/plugin that directly supports all the advanced features in GIT including Egit, intellij and others.
  - mataug 13y ago
    I doubt if any tool can ever support all the advanced features of GIT like its plumbing commands. Even a feature like rebase is which is fairly understandable on the CLI, becomes difficult to use on a GUI
  - andyhmltn 13y ago
    I would assume that being able to work offline and not depend on a central repo is enough of a benefit anyhow
    - mataug 13y ago
      I don't this is really a killer feature in this age of always connected devices.
      - andyhmltn 13y ago
        If you've ever tried to get a decent connection on a train through England on a particular network, you'd disagree :)

millstone 13y ago

I think this article does not do the svn workflow justice. Svn was designed with the inherent assumption that the context of a developer within any single codebase would be linear This may be how the engineers in question used svn, but that's certainly not how svn was designed! Creating a branch in Subversion is not difficult or expensive. It's natural for each engineer on a team to have a separate svn directory containing "private" branches. If engineers are committing unstable code to the trunk, they're doing it wrong. Git branching is also cheap and quick, unlike svn in which a branching creating a new copy of code. Git also preserves history when branching, unlike Svn. Subversion uses copy-on-write when creating a branch, so it is not expensive. Subversion also records the branch event in the file's history. It sounds like the team had a flawed understanding of svn, and was using a terrible workflow. The benefits of the switch are not due to git, but to investing actual time learning a scm tool. That same time invested into learning svn would have paid equal dividends.

taspeotis 13y ago
> Subversion uses copy-on-write when creating a branch, so it is not expensive It doesn't matter what the server does, it's relatively slow on the client to either switch to or checkout a branch.
- raimue 13y ago
  On the plus side, you can have multiple local branches side-by-side with svn easily, which is much easier to work with for beginners as they can just view and compare the trees in the filesystem. With git, such a setup requires more understanding on how to make a local clone instead of fetching the full history from the server multiple times.
  - Dylan16807 13y ago
    Fetching the full history in git is often less data than a checkout in svn. Also you could just copy the folder. Edit: git-new-workdir looks like it makes things convenient.
- 13y ago

tehwalrus 13y ago

The way I handled branching in SVN was to have several checkouts of the same trunk, and run "svn update" to fast-forward before committing (once my patch had passed code review.) Hard drives are cheap, brain cells expensive! (note, this model works fine when you have a big company machine sat in an office on gigabit LAN to the SVN server - break any of the assumptions there, and SVN quickly deteriorates. I'm not saying git isn't better, just than SVN isn't that bad where I encountered it.)

Peaker 13y ago
Hard drives are slow. Copying a huge working tree to make a small branch makes no sense.
- tehwalrus 13y ago
  I would just permanently maintain 4 or 5 checkouts of active projects, and rename the containing directories for branch names. I know git is better, I'm just saying SVN can be used in a similar way, if less efficiently.

deleted 13y ago

[deleted]

Peaker 13y ago
The ability to reorder commits, split them, squash them, etc in an interactive Rebase is unparalleled in svn, which necessarily means lower quality history. Working with higher quality history when merging, cherry picking, reverting, etc is much more productive. Understanding code with high quality history is easier too.