5 ms·

Could you explain what's wrong with that answer? I found it to be spot on, but then again maybe I'm 'clueless' as well.

chris_wot 13y ago
The whole point of a DVCS is to be decentralized. Linus Torvalds often just posts his own repository and others pull from it. You can use it as a centralized repo, and it works quite well. In fact, it's how I'm doing development with LibreOffice via gerrit. However, even there I find it easier. I find my workflow is to work on a branch, make sure I have clean commits (I use rebase pretty frequently) and branch and merge often. Frankly, it's easier to work with. I find the staging model to be really excellent, and find it just easier to move up and down commits. But looking at the quotes: Git seems to be the "new, shiny, cool" thing. No, no it's not. Two modes of creating repositories Well, sure. It's literally just a shortcut for setting up groups and then changing a global setting. Repos can go from bare to shared reasonably easily. I fail to see the point. checkout vs. clone Checkout checks out a branch of path to the working directory. Clone gets an entire repository and "clones" it to the current directory. There is no "versus" here, they are two completely different operations. commit vs. push Commit records the changes to the local repository. Push basically takes a ref (a mapping to a sha-1 value that identifies a commit in the tree) and updates a ref in a remote repository. In essence, you are pushing your changes to the remote repository. Again, the thinking of a VCS person, not someone used to DVCSes. You have to know which commands work locally and which work with "the server" Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many ways. Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. The whole point of git is that you have your version, and you either pull from or push to different repositories and and when needed. The whole idea of centralization is not core to it at all.
- einhverfr 13y ago
  > Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many ways. The benefits come at a cost though (I say this as someone who works with both). For many environments, a centralized VCS is all you need. Making it distributed just because that's a popular thing to do isn't necessarily always a good idea. It complicates workflows because now you have to have multiple version control systems which interact with eachother in far more complex ways. You don't want to go down that path if you don't need to. Now, despite the costs, there are many advantages to git. These include an ability to effectively treat your local repo as a master for a client. Also DVCS's scale to a larger number of developers more than traditional VCS's and git has advantages there too. BTW. one thing I find to be a killer feature of github is the fact that it offers you svn access to git repos, which can be really, really nice.
  - chris_wot 13y ago
    Well, no. If you have a centralized git server (can be done), then you have the following workflow: 1. Make your changes, branch, do whatever you want to do. 2. Commit the changes to your repo. 3. Push your changes to the remote repo. 4. When you want to get other's changes, pull those changes. Heck, do a git pull -r if you want to rebase them. That is really not that complicated. However, you get the benefits of a local copy. So not what I'd really call totally distributed, but I can't see any downsides to this.
    - einhverfr 13y ago
      > That is really not that complicated. It's still twice as many steps. Well, probably more if you count git add before every commit. Also a big problem for me is the necessity of a git add * before a commit, which effectively requires a lot of management of .gitignore so you don't get things like the Makefile.old getting committed. Keep in mind, all of this is process overhead, an opportunity to make mistakes, and effort (including tracking/fixing the mistakes) that could be spent programming. There are downsides. As I say, I do a fair bit with both and to be honest I am not that enthusiastic about git over svn. It's really good in some cases. However it isn't always better. Sometimes simpler tools are better.
      - pjc50 13y ago
        "git add -u" behaves better. Personally (as a near-beginner) I have no end of trouble with the push/pull workflow. You can't pull if you have files edited, but you can't push if you're behind. 'git stash' makes this a bit less painful.
  - pjc50 13y ago
    Indeed - which system is best depends on your workflow. For small to medium teams structured in a top-down business way, svn is easier to understand. git generates a lot more merging (every pull is a merge). A distributed VCS is very useful if you have a distributed team. If you don't, the distributed aspect is simply not very relevant.
  - 13y ago
- tehwalrus 13y ago
  > "checkout vs. clone", "commit vs. push" The author's comments here refer to the different uses of the same commands/names in git and subversion, they are not getting git commands wrong. svn commit is roughly equivalent to: git commit && git push although there is no equivalent to git commit in subversion, which is where the confusion that they are pointing out arises. Similarly: svn checkout is roughly equivalent to: git clone and there is simply no equivalent to git checkout in subversion.
  - chris_wot 13y ago
    Oh! Oops... I see what you mean. That's a fair point... I thought he was comparing equivalent git commands! Read that way that makes a lot more sense.
    - m_mueller 13y ago
      In light of this comment I think there was just a misunderstanding between us. Sorry for the snark.
      - chris_wot 13y ago
        Yeah, as do I. I acted a bit childishly. Sorry :(
- m_mueller 13y ago
  I'm a bit annoyed at how the discussion here has turned out. Did you actually read the post you're criticizing instead of just jumping at the first critical points he makes about git because it happens to be your favorite tool? No argument you list here is in any way contradicting to what the post says. To summarize again, the post says: Git is more powerful because it's distributed - but that comes at a price in terms of a more complex UI. If you know that you'll never need DVCS, you might be better off using SVN. Everything you are listing here is examples of how git's UI is more complex, except you don't seem to recognize it anymore because git has become so engrained in what you do. Every so often it's worth it to take a step back, to look at our workflows and to figure out why we do what we do for every step. This SO reply was IMO a good attempt at explaining exactly this in terms of the Git vs. SVN discussion.
  - chris_wot 13y ago
    I'm a bit annoyed at how your response to me has turned out. Did you actually read my response which you're criticizing instead of jumping at the first "critical points" I make about the comments made about git by the user? Or is it because git is not your favourite tool? No argument you list here is in any way contradicting what I said. Yes, I did indeed read the post. I wasn't jumping at "critical points", I was pointing out that he doesn't seem to have his head around a DVCS like git. As I've pointed out a few times, the UI is not really more complex. There is literally one more step - git push - to have your changes "pushed" to a remote repo.
    - chris_wot 13y ago
      I'll not edit the above reply. But I'm sorry I wrote that the way I did. It was very snarky and unnecessary. Apologies for bringing down the tone of the thread. :(
- jmccree 13y ago
  I think what you're missing is DVCS is a subset of "version control". A large percent of developers have moved from CVS to SVN and for the past few years are hearing Git is the successor to SVN. So they are comparing the new hot version control Git to their previous SVN. A lot of these people don't care about the distributed aspect, just whether git is better than svn for their version controlling needs. I think the thing that generated much of the initial git confusion for svn users was a lot of the git documentation at the time were devoted to using git in a very distributed, very branching, type of of manner, which while it's awesome that it's possible, is needless complexity for many dev teams. Particularly this post was passed around as the gold standard: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ . A lot of svn devs were used to a pretty simple work flow. Checkout the current branch in dev, make some edits, commit/push. Rinse, repeat. On many teams no one other than the lead dev/release master would ever need to even do a merge. Now show this team the above git branching model, which suggest Bob can pull a feature branch over from Alice, make some commits and push back, but wait Sam has also needed to pull Alice's to make some commits, and merges in her latest changes from Develop which conflict with both Bob and Alices current. Now you have the lead dev or release manager wasting hours trying to figure out this merge mess with 3 broken repos and the PM demanding Sam's changes in develop are needed for a hotfix by Pat yesterday. I hope you can see the massive complexity increase in the way a lot of teams were initially told to use Git. Once people figured out everyone could pull and push from a centralized repo (Github heavily helped this) and that branches should (for a certain type of dev team) always be pushed/pulled from the central repo instead of shared peer to peer, the workflow was much simplified. Git with a central repo is more than likely better than using svn for many teams. The easy branching and offline commits are benefits whether a team needs the "distributed" aspect or not. It's apparent that you really understand and use a DCVS, many people do not. It's important to realize on many projects devs don't want or need to become experts on DCVS, but could still benefit from using Git over svn. For a lot of open source projects, merging and reviewing patches is a big part of the project as that's how new code gets in. For a startup team, any time spent on dealing with a VCS system is time not spent developing the product.
  - chris_wot 13y ago
    You make some interesting points, but I suppose that I take issue that branching is a particularly complex thing. IMO, branching allows you to make changes without affecting the mainline code, then the merge points allow you to get back to contributing back to the codebase. I think it's odd though that you use the example that someone checks out the current branch, makes some edits, then commits back in the changes. You have the same problem you highlight - if someone else makes changes, then you get the same merging issues, only this time it's on the main branch. You will still get the same project managers screaming for a hotfix, and you'll still get the same problems of merging in the changes that were checked out. After all, SVN doesn't prevent others from checking out the same files and commiting changes whilst you are making changes. BTW, what do you mean that a DVCS is a subset of version control?

The whole point of a DVCS is to be decentralized. Linus Torvalds often just posts his own repository and others pull from it. You can use it as a centralized repo, and it works quite well. In fact, it's how I'm doing development with LibreOffice via gerrit. However, even there I find it easier. I find my workflow is to work on a branch, make sure I have clean commits (I use rebase pretty frequently) and branch and merge often. Frankly, it's easier to work with. I find the staging model to be really excellent, and find it just easier to move up and down commits. But looking at the quotes: Git seems to be the "new, shiny, cool" thing. No, no it's not. Two modes of creating repositories Well, sure. It's literally just a shortcut for setting up groups and then changing a global setting. Repos can go from bare to shared reasonably easily. I fail to see the point. checkout vs. clone Checkout checks out a branch of path to the working directory. Clone gets an entire repository and "clones" it to the current directory. There is no "versus" here, they are two completely different operations. commit vs. push Commit records the changes to the local repository. Push basically takes a ref (a mapping to a sha-1 value that identifies a commit in the tree) and updates a ref in a remote repository. In essence, you are pushing your changes to the remote repository. Again, the thinking of a VCS person, not someone used to DVCSes. You have to know which commands work locally and which work with "the server" Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many ways. Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. The whole point of git is that you have your version, and you either pull from or push to different repositories and and when needed. The whole idea of centralization is not core to it at all.

einhverfr 13y ago
> Only if you think in terms of centralized repositories. A DVCS is distributed. It's a completely different way of thinking. I find it superior in very many ways. The benefits come at a cost though (I say this as someone who works with both). For many environments, a centralized VCS is all you need. Making it distributed just because that's a popular thing to do isn't necessarily always a good idea. It complicates workflows because now you have to have multiple version control systems which interact with eachother in far more complex ways. You don't want to go down that path if you don't need to. Now, despite the costs, there are many advantages to git. These include an ability to effectively treat your local repo as a master for a client. Also DVCS's scale to a larger number of developers more than traditional VCS's and git has advantages there too. BTW. one thing I find to be a killer feature of github is the fact that it offers you svn access to git repos, which can be really, really nice.
- chris_wot 13y ago
  Well, no. If you have a centralized git server (can be done), then you have the following workflow: 1. Make your changes, branch, do whatever you want to do. 2. Commit the changes to your repo. 3. Push your changes to the remote repo. 4. When you want to get other's changes, pull those changes. Heck, do a git pull -r if you want to rebase them. That is really not that complicated. However, you get the benefits of a local copy. So not what I'd really call totally distributed, but I can't see any downsides to this.
  - einhverfr 13y ago
    > That is really not that complicated. It's still twice as many steps. Well, probably more if you count git add before every commit. Also a big problem for me is the necessity of a git add * before a commit, which effectively requires a lot of management of .gitignore so you don't get things like the Makefile.old getting committed. Keep in mind, all of this is process overhead, an opportunity to make mistakes, and effort (including tracking/fixing the mistakes) that could be spent programming. There are downsides. As I say, I do a fair bit with both and to be honest I am not that enthusiastic about git over svn. It's really good in some cases. However it isn't always better. Sometimes simpler tools are better.
    - pjc50 13y ago
      "git add -u" behaves better. Personally (as a near-beginner) I have no end of trouble with the push/pull workflow. You can't pull if you have files edited, but you can't push if you're behind. 'git stash' makes this a bit less painful.
- pjc50 13y ago
  Indeed - which system is best depends on your workflow. For small to medium teams structured in a top-down business way, svn is easier to understand. git generates a lot more merging (every pull is a merge). A distributed VCS is very useful if you have a distributed team. If you don't, the distributed aspect is simply not very relevant.
- 13y ago
tehwalrus 13y ago
> "checkout vs. clone", "commit vs. push" The author's comments here refer to the different uses of the same commands/names in git and subversion, they are not getting git commands wrong. svn commit is roughly equivalent to: git commit && git push although there is no equivalent to git commit in subversion, which is where the confusion that they are pointing out arises. Similarly: svn checkout is roughly equivalent to: git clone and there is simply no equivalent to git checkout in subversion.
- chris_wot 13y ago
  Oh! Oops... I see what you mean. That's a fair point... I thought he was comparing equivalent git commands! Read that way that makes a lot more sense.
  - m_mueller 13y ago
    In light of this comment I think there was just a misunderstanding between us. Sorry for the snark.
    - chris_wot 13y ago
      Yeah, as do I. I acted a bit childishly. Sorry :(
m_mueller 13y ago
I'm a bit annoyed at how the discussion here has turned out. Did you actually read the post you're criticizing instead of just jumping at the first critical points he makes about git because it happens to be your favorite tool? No argument you list here is in any way contradicting to what the post says. To summarize again, the post says: Git is more powerful because it's distributed - but that comes at a price in terms of a more complex UI. If you know that you'll never need DVCS, you might be better off using SVN. Everything you are listing here is examples of how git's UI is more complex, except you don't seem to recognize it anymore because git has become so engrained in what you do. Every so often it's worth it to take a step back, to look at our workflows and to figure out why we do what we do for every step. This SO reply was IMO a good attempt at explaining exactly this in terms of the Git vs. SVN discussion.
- chris_wot 13y ago
  I'm a bit annoyed at how your response to me has turned out. Did you actually read my response which you're criticizing instead of jumping at the first "critical points" I make about the comments made about git by the user? Or is it because git is not your favourite tool? No argument you list here is in any way contradicting what I said. Yes, I did indeed read the post. I wasn't jumping at "critical points", I was pointing out that he doesn't seem to have his head around a DVCS like git. As I've pointed out a few times, the UI is not really more complex. There is literally one more step - git push - to have your changes "pushed" to a remote repo.
  - chris_wot 13y ago
    I'll not edit the above reply. But I'm sorry I wrote that the way I did. It was very snarky and unnecessary. Apologies for bringing down the tone of the thread. :(
jmccree 13y ago
I think what you're missing is DVCS is a subset of "version control". A large percent of developers have moved from CVS to SVN and for the past few years are hearing Git is the successor to SVN. So they are comparing the new hot version control Git to their previous SVN. A lot of these people don't care about the distributed aspect, just whether git is better than svn for their version controlling needs. I think the thing that generated much of the initial git confusion for svn users was a lot of the git documentation at the time were devoted to using git in a very distributed, very branching, type of of manner, which while it's awesome that it's possible, is needless complexity for many dev teams. Particularly this post was passed around as the gold standard: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ . A lot of svn devs were used to a pretty simple work flow. Checkout the current branch in dev, make some edits, commit/push. Rinse, repeat. On many teams no one other than the lead dev/release master would ever need to even do a merge. Now show this team the above git branching model, which suggest Bob can pull a feature branch over from Alice, make some commits and push back, but wait Sam has also needed to pull Alice's to make some commits, and merges in her latest changes from Develop which conflict with both Bob and Alices current. Now you have the lead dev or release manager wasting hours trying to figure out this merge mess with 3 broken repos and the PM demanding Sam's changes in develop are needed for a hotfix by Pat yesterday. I hope you can see the massive complexity increase in the way a lot of teams were initially told to use Git. Once people figured out everyone could pull and push from a centralized repo (Github heavily helped this) and that branches should (for a certain type of dev team) always be pushed/pulled from the central repo instead of shared peer to peer, the workflow was much simplified. Git with a central repo is more than likely better than using svn for many teams. The easy branching and offline commits are benefits whether a team needs the "distributed" aspect or not. It's apparent that you really understand and use a DCVS, many people do not. It's important to realize on many projects devs don't want or need to become experts on DCVS, but could still benefit from using Git over svn. For a lot of open source projects, merging and reviewing patches is a big part of the project as that's how new code gets in. For a startup team, any time spent on dealing with a VCS system is time not spent developing the product.
- chris_wot 13y ago
  You make some interesting points, but I suppose that I take issue that branching is a particularly complex thing. IMO, branching allows you to make changes without affecting the mainline code, then the merge points allow you to get back to contributing back to the codebase. I think it's odd though that you use the example that someone checks out the current branch, makes some edits, then commits back in the changes. You have the same problem you highlight - if someone else makes changes, then you get the same merging issues, only this time it's on the main branch. You will still get the same project managers screaming for a hotfix, and you'll still get the same problems of merging in the changes that were checked out. After all, SVN doesn't prevent others from checking out the same files and commiting changes whilst you are making changes. BTW, what do you mean that a DVCS is a subset of version control?