10 ms·

> 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 w

by 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]
  - dexen 16y ago
    Merging about 240 files from big-change-branch into the main branch and also merging a small, incremental development branch into main at the same moment is a tight spot whatever version control you use. Nothing worked anymore and the IDE managed only to spew out a dialog error saying `Nieprawid.'. In git, cleaning the server up took just some command typing on developer machine. Could have been done from TortoiseGit, if they wanted to. The best thing is, the clean-up was `perfect' in that it left no traces of the fubar whatsoever. No faux merge left to trip up future merges by mis-placing the base version. Yay <3
    - nupark 16y ago
      Being able to disappear/discard history has significant downsides, too. Regardless, you can rollback changes in subversion without bungling future merges.
      - dexen 16y ago
        > Being able to disappear/discard history has significant downsides, too. Yes and no. You can remove something from history if all holders of the copies agree with that. You can't forcefully remove anything from anybody's history if they don't actively cooperate. So no malicious data loss possible, but an agreed-upon cleanup is. Nb., in SVN only a central repo holds the full history. Should the admin remove some changeset, there's no way to check, or prove, that it ever was there. That is a (formal, legal etc) problem in certain situations. With Git, once you've fetched a changeset, it's there, all yours (till you explicitly remove it). In SVN, should a malicious blackhat break in and add backdoor to code in a central repo, noone will notice. In Git, correctness and consistency is ensured courtesy of SHA1. In Git and in SVN you can alter history. In Git, it's either `everybody agrees' or `somebody notices something went haywire because changeset chain doesn't match'. In SVN, it's `I trust the central repo with everything, fingers crossed'.
        nupark 16y ago
        > Yes and no. You can remove something from history if all holders of the copies agree with that. You can't forcefully remove anything from anybody's history if they don't actively cooperate. These features also make it very easy to make mistakes with your own local repository, and propagate those mistakes upstream (even if they can then be detected and resolved), which was the original poster's point, as I recall. > In SVN, it's `I trust the central repo with everything, fingers crossed'. In reality, this isn't an issue for organizations, and decentralization introduces a considerable amount of complexity that confuses most users. Businesses already rely on the correctness of centralized resources and have straight-forward processes to monitor and maintain them -- be it accounting data, a centralized CA, their corporate directory and payroll system, or SCM. Ignoring the fact that this level of validation largely unnecessary -- if I were going to modify subversion to institute better validation of data, I would implement PKI signing of commits, not decentralization of the repository. Git has some support for this, but honestly this is not very high on the list of most organization's priorities, and largely only matters more for open source projects, if at all.
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

by durin42 16y ago

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]
- dexen 16y ago
  Merging about 240 files from big-change-branch into the main branch and also merging a small, incremental development branch into main at the same moment is a tight spot whatever version control you use. Nothing worked anymore and the IDE managed only to spew out a dialog error saying `Nieprawid.'. In git, cleaning the server up took just some command typing on developer machine. Could have been done from TortoiseGit, if they wanted to. The best thing is, the clean-up was `perfect' in that it left no traces of the fubar whatsoever. No faux merge left to trip up future merges by mis-placing the base version. Yay <3
  - nupark 16y ago
    Being able to disappear/discard history has significant downsides, too. Regardless, you can rollback changes in subversion without bungling future merges.
    - dexen 16y ago
      > Being able to disappear/discard history has significant downsides, too. Yes and no. You can remove something from history if all holders of the copies agree with that. You can't forcefully remove anything from anybody's history if they don't actively cooperate. So no malicious data loss possible, but an agreed-upon cleanup is. Nb., in SVN only a central repo holds the full history. Should the admin remove some changeset, there's no way to check, or prove, that it ever was there. That is a (formal, legal etc) problem in certain situations. With Git, once you've fetched a changeset, it's there, all yours (till you explicitly remove it). In SVN, should a malicious blackhat break in and add backdoor to code in a central repo, noone will notice. In Git, correctness and consistency is ensured courtesy of SHA1. In Git and in SVN you can alter history. In Git, it's either `everybody agrees' or `somebody notices something went haywire because changeset chain doesn't match'. In SVN, it's `I trust the central repo with everything, fingers crossed'.
      - nupark 16y ago
        > Yes and no. You can remove something from history if all holders of the copies agree with that. You can't forcefully remove anything from anybody's history if they don't actively cooperate. These features also make it very easy to make mistakes with your own local repository, and propagate those mistakes upstream (even if they can then be detected and resolved), which was the original poster's point, as I recall. > In SVN, it's `I trust the central repo with everything, fingers crossed'. In reality, this isn't an issue for organizations, and decentralization introduces a considerable amount of complexity that confuses most users. Businesses already rely on the correctness of centralized resources and have straight-forward processes to monitor and maintain them -- be it accounting data, a centralized CA, their corporate directory and payroll system, or SCM. Ignoring the fact that this level of validation largely unnecessary -- if I were going to modify subversion to institute better validation of data, I would implement PKI signing of commits, not decentralization of the repository. Git has some support for this, but honestly this is not very high on the list of most organization's priorities, and largely only matters more for open source projects, if at all.

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