3 ms·

The reason git works so well is because it models real life. When you check out a tree to work on it, the moment you change a file in your editor you have forke

by rlpb 12y ago

The reason git works so well is because it models real life. When you check out a tree to work on it, the moment you change a file in your editor you have forked the tree. Whether you save the changes or not, it's a fork, even if a temporary one. More than that, it's a distributed fork. What your undo buffer in your editor does, or your local filesystem does, or your VCS does, is merely an implementation detail. It works well to be using a tool where the changes you make in your editor are unified with the more formal changes you'll be pushing back upstream. It makes the whole process smoother, and means that all editing involves an identical workflow. Even with Subversion, for example: if you make a local change in a file concurrent to something being changed in the repository, then what you have is a diverging branch. Subversion will try to auto-merge when your commit fails and you update your working tree (IIRC). Just because Subversion neither calls your working tree a branch nor your update a merge doesn't stop them being so. My point is that if you're changing code that is also being worked on elsewhere, you are using a DVCS whether you like it or not. Even if you aren't even using a specific DVCS tool. You have a DVCS the moment two people work on the same code base concurrently. So you might as well use a tool that integrates with the workflow that you already have.

DominikD 12y ago
This is not real life, this is a workflow, one of many. It happens to mirror mine though and, perhaps surprisingly, I can easily achieve the same workflow with centralized VCS by using branches. It would be a major pain in CVS but works just fine for me (and others) in Perforce. So it can be done. What's interesting is what "it" means" and that you're proving one of the points author is making: your workflow doesn't rely on the fact that your VCS is decentralized. It relies on the fact that branching/forking is easy. Painful branching is quite often a matter of legacy since CVS and SVN were architected in different times when our needs were mostly different and technology was very different.

by rlpb 12y ago

DominikD 12y ago

This is not real life, this is a workflow, one of many. It happens to mirror mine though and, perhaps surprisingly, I can easily achieve the same workflow with centralized VCS by using branches. It would be a major pain in CVS but works just fine for me (and others) in Perforce. So it can be done. What's interesting is what "it" means" and that you're proving one of the points author is making: your workflow doesn't rely on the fact that your VCS is decentralized. It relies on the fact that branching/forking is easy. Painful branching is quite often a matter of legacy since CVS and SVN were architected in different times when our needs were mostly different and technology was very different.