7 ms·

Do not confuse elitism with minimalism. Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows.

by yuvadam 16y ago

Do not confuse elitism with minimalism. Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). When branching in git is a simple git checkout -b newbranch away as opposed to svn copy http://repo.com/some/path/to/trunk http://repo.com/some/path/to/trunk http://repo.com/some/path/to/branches/somenewbranch http://repo.com/some/path/to/branches/somenewbranch - then what else is there to say, really? Sure, svn is extremely easy to setup and use in small teams. But it is simply not geared towards modern development flows. I appreciate tools that appreciate my time (and sanity) as a developer. And git does just that.

durin42 16y ago
> Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). I don't know. I've trained a lot of developers with Subverison, Git, and Mercurial. Subversion is the one that I've honestly had the least trouble with, and Git the most. Heck, early on with git I had instances where the repo was so wedged I had to just torch .git and start over. I know more now and can get out of it, but with Subversion I've never* seen a user-facing command that causes Subversion to become mystically wedged and require a new repository for non-advanced users.
- dexen 16y ago
  Perhaps you want to re-read on git-reset. You can always rewind history to some arbitrary point and re-stack operations, both en-mass and step by step You can re-write branches locally and even on the server. It's to be used very rarely & carefully, but it has gotten the other team at my workplace out of a tight spot just two days ago.
  - nupark 16y ago
    Whereas with a simpler tool like subversion, there will be no tight spots.
    - danssig 16y ago
      I would downvote this post if I had the power. It's wrong to the point to either be lying or trolling.
      - nupark 16y ago
        Since you can't downvote, you could try explaining your position.
        danssig 16y ago
        I did: the post is nonsensical. Can't get into tight spots with SVN? It's hard to imagine anyone that's actually used SVN saying that.
        nupark 16y ago
        Subversion is simple enough that while you can find ways to mess up your local working copy, it's much harder to destroy previous work (in your local branch or upstream) or otherwise make a mess. Git is a complex, fragile (in the wrong hands) VCS.
        danssig 16y ago
        > it's much harder to destroy previous work (in your local branch or upstream) or otherwise make a mess More falsehoods. While it may be true that it's harder to corrupt the central repo (as opposed to your copy of it) [1], it's hard to lose work in Git even locally. Git is not fragile, nor complex. It has more features than SVN since it has more capabilities but most of the stuff just works. It sounds to me like you don't really know much about Git. If you think you lost a change, you probably didn't. Unless a GC has happened the change is still in the repo, you just don't have any pointers to it. You just need to query the db for it (or if you know the hash code you can use that) and make a branch or tag to the revision when you find it. Ironically, I find Git much more stable than SVN because in Git change sets are first class and cryptographically signed. I can always find the exact one I was previously working with if need be. Changes not being first class in SVN means you can't tell if you're looking the original change, the result of a merge, etc. [1] It can be done pretty simply with branching though. If you share branches with each other it is possible to set up a situation where all further checkins for most users will create a large amount (depending on the previous branches) of fake conflicts. [1]
- jshen 16y ago
  It sounds like you were training people on git when you didn't know git very well. That's an odd way to judge git.
  - hollerith 16y ago
    Not if he put equal amounts of effort into learning git, svn and hg.
    - jshen 16y ago
      If someone says svn is easier it's because they don't do significant branching. Git and hg allow you to branch sanely. Subversion doesn't. Someone that doesn't get this hasn't learned much.
      - nupark 16y ago
        What do you mean by 'sane', and how does subversion (which includes merge tracking) fail to meet your definition?
        jshen 16y ago
        It's not a DAG. Since you know that subversion has merge tracking since 1.5 I'm going to assume you know what I mean. I don't have time or space in a comment to explain why this is so much better. For an example or two: http://stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy http://stackoverflow.com/questions/2613525/what-makes-mergin... http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/2486662#2486662 http://stackoverflow.com/questions/2475831/merging-hg-git-vs...
        nupark 16y ago
        I don't have time or space in a comment to explain why this is so much better. Better in practice, or better in theory? In practice, I personally haven't found that it makes a difference, and that the majority of cost in merging is in keeping abreast of functional differences, not in line-by-line conflict resolution. YMMV, but I don't think it's as clear cut as you make it out to be.
- dustingetz 16y ago
  i'd love to see a blog post on this, because im probably leading a migration at work and I can't think of a situation like that.
- bad_user 16y ago
  I've never* seen a user-facing command that causes Subversion to become mystically wedged and require a new repository for non-advanced users. It happened to me 3 times already, with my local copy ending up in limbo - as weird stuff can happen when you're deleting a directory locally, with another dev having made changes to its files. And torching .git and starting over is easier than doing the same with SVN ;) That's why I'm using git-svn; even when I have to use SVN.
- dexen 16y ago
  Any very wrong merge[1] may leave the central repo in `working but contains nonsensical data' state. In SVN you can only commit a reverting changeset or you can alter the state of the server. The former leaves the merge around to trip up future merges; the later requires you to have admin access to the server and may break user's checkouts. In git, you can just push a clean branch on the server, if you take some caution. No elevated privileges needed. Actually, most of the time it won't be necessary, because the user will simply not push a wrong merge to the server. No need to clean up. Actually once in a while I do torch whole repo (both .git and checked out files), but that's only when I was experimenting with something and didn't like the result. Cheap local cloning of Git repos makes that experimentation fast, easy & safe. On the other hand, if I ever have to really, positively clean the repo to a known state, `git co -f $SOME_BRANCH' or `git co -f HEAD'; end of the story. Perhaps also remove the leftover untracked files, if I was cleaning merge abandoned in progress. -- [1] as I described here: http://news.ycombinator.com/item?id=2310065 http://news.ycombinator.com/item?id=2310065
deleted 16y ago
[deleted]

by yuvadam 16y ago

durin42 16y ago

> Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). I don't know. I've trained a lot of developers with Subverison, Git, and Mercurial. Subversion is the one that I've honestly had the least trouble with, and Git the most. Heck, early on with git I had instances where the repo was so wedged I had to just torch .git and start over. I know more now and can get out of it, but with Subversion I've never* seen a user-facing command that causes Subversion to become mystically wedged and require a new repository for non-advanced users.

dexen 16y ago
Perhaps you want to re-read on git-reset. You can always rewind history to some arbitrary point and re-stack operations, both en-mass and step by step You can re-write branches locally and even on the server. It's to be used very rarely & carefully, but it has gotten the other team at my workplace out of a tight spot just two days ago.
- nupark 16y ago
  Whereas with a simpler tool like subversion, there will be no tight spots.
  - danssig 16y ago
    I would downvote this post if I had the power. It's wrong to the point to either be lying or trolling.
    - nupark 16y ago
      Since you can't downvote, you could try explaining your position.
      - danssig 16y ago
        I did: the post is nonsensical. Can't get into tight spots with SVN? It's hard to imagine anyone that's actually used SVN saying that.
        nupark 16y ago
        Subversion is simple enough that while you can find ways to mess up your local working copy, it's much harder to destroy previous work (in your local branch or upstream) or otherwise make a mess. Git is a complex, fragile (in the wrong hands) VCS.
        danssig 16y ago
        > it's much harder to destroy previous work (in your local branch or upstream) or otherwise make a mess More falsehoods. While it may be true that it's harder to corrupt the central repo (as opposed to your copy of it) [1], it's hard to lose work in Git even locally. Git is not fragile, nor complex. It has more features than SVN since it has more capabilities but most of the stuff just works. It sounds to me like you don't really know much about Git. If you think you lost a change, you probably didn't. Unless a GC has happened the change is still in the repo, you just don't have any pointers to it. You just need to query the db for it (or if you know the hash code you can use that) and make a branch or tag to the revision when you find it. Ironically, I find Git much more stable than SVN because in Git change sets are first class and cryptographically signed. I can always find the exact one I was previously working with if need be. Changes not being first class in SVN means you can't tell if you're looking the original change, the result of a merge, etc. [1] It can be done pretty simply with branching though. If you share branches with each other it is possible to set up a situation where all further checkins for most users will create a large amount (depending on the previous branches) of fake conflicts. [1]
jshen 16y ago
It sounds like you were training people on git when you didn't know git very well. That's an odd way to judge git.
- hollerith 16y ago
  Not if he put equal amounts of effort into learning git, svn and hg.
  - jshen 16y ago
    If someone says svn is easier it's because they don't do significant branching. Git and hg allow you to branch sanely. Subversion doesn't. Someone that doesn't get this hasn't learned much.
    - nupark 16y ago
      What do you mean by 'sane', and how does subversion (which includes merge tracking) fail to meet your definition?
      - jshen 16y ago
        It's not a DAG. Since you know that subversion has merge tracking since 1.5 I'm going to assume you know what I mean. I don't have time or space in a comment to explain why this is so much better. For an example or two: http://stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy http://stackoverflow.com/questions/2613525/what-makes-mergin... http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/2486662#2486662 http://stackoverflow.com/questions/2475831/merging-hg-git-vs...
        nupark 16y ago
        I don't have time or space in a comment to explain why this is so much better. Better in practice, or better in theory? In practice, I personally haven't found that it makes a difference, and that the majority of cost in merging is in keeping abreast of functional differences, not in line-by-line conflict resolution. YMMV, but I don't think it's as clear cut as you make it out to be.
dustingetz 16y ago
i'd love to see a blog post on this, because im probably leading a migration at work and I can't think of a situation like that.
bad_user 16y ago
I've never* seen a user-facing command that causes Subversion to become mystically wedged and require a new repository for non-advanced users. It happened to me 3 times already, with my local copy ending up in limbo - as weird stuff can happen when you're deleting a directory locally, with another dev having made changes to its files. And torching .git and starting over is easier than doing the same with SVN ;) That's why I'm using git-svn; even when I have to use SVN.
dexen 16y ago
Any very wrong merge[1] may leave the central repo in `working but contains nonsensical data' state. In SVN you can only commit a reverting changeset or you can alter the state of the server. The former leaves the merge around to trip up future merges; the later requires you to have admin access to the server and may break user's checkouts. In git, you can just push a clean branch on the server, if you take some caution. No elevated privileges needed. Actually, most of the time it won't be necessary, because the user will simply not push a wrong merge to the server. No need to clean up. Actually once in a while I do torch whole repo (both .git and checked out files), but that's only when I was experimenting with something and didn't like the result. Cheap local cloning of Git repos makes that experimentation fast, easy & safe. On the other hand, if I ever have to really, positively clean the repo to a known state, `git co -f $SOME_BRANCH' or `git co -f HEAD'; end of the story. Perhaps also remove the leftover untracked files, if I was cleaning merge abandoned in progress. -- [1] as I described here: http://news.ycombinator.com/item?id=2310065 http://news.ycombinator.com/item?id=2310065

deleted 16y ago

[deleted]