On Tue, Jul 21, 2009 at 11:08:31PM -0600, Tim Harper wrote: > > How has mastering the advanced features of git helped you to be a > better programmer? I don't think that features itself make as big difference as the fact Git provides you much more flexibility in choosing a more appropriate workflow than you have with any centralized VCS. (Yes, you will still find many Git features handy even if you work with it as you did with CVS, but you will miss most benefits of Git). To really understand what benefits Git offers, you have to realize first what is wrong CVS and CVS-like VCSes. Unfortunately, it is difficult to explain just in a few words. Some implementation deficiency of CVS is obvious (and it was addressed in some CVS clones like Subversion), but more fundamental problems are far less obvious even for people who used CVS for many years. To be fair to CVS, it is far from the worst VCS. There are some insane lock-based VCS, which were so painful to use (mostly due to these exclusive locks but often due to some other insanity too) that anyone who worked with may think about CVS as a really nice system... In some way, CVS was really revolutionary for its time, because it used the copy-modify-merge paradigm instead of excluding locking, which was dominant before the CVS era. Those exclusive locks not only could not work over the Internet, they were so excruciatingly annoying even if everyone was sitting in the same room... Despite some initial skepticism about essentially the lock-free VCS, I think it is safe to say now that the copy-modify-merge paradigm won. Period. However, if you look at the support of this paradigm in CVS and other centralized VCSes, it is very limited in every aspect: - copy: you can have a copy only one revision. (it may not be a big issue unless you like to work offline and to look at history). - modify: there is no problem with modification itself, but you cannot save your changes without committing that to the official repo, which is not such a good thing if they are not ready yet or were not reviewed properly. - merge: well.. I don't think there is any sane person who enjoyed merging branches in CVS... The only merge that was _relatively_ easy to do was merging your worktree with the upstream. Even that is not perfect in CVS, because you cannot save your changes before merge. So, if you made a mistake during 'cvs update', you risk to losing your work... Also, there is no possibility to review the merge later or to delegate to someone else when its resolution happens to be tricky... The above limitations have further consequences with negatively affect co-operation among developers. For instance, it is very difficult to organize the review process with any centralized VCS. Typically, a review process may require saving and share your work with reviewer without committing it to the central repo. Also, this work should be split into logical steps to make review easier. The only way to do that with a centralized VCS is to use some patch management system on top of it.... and at that point you may ask whether you want to learn two systems with overlapping functionality and not so well integrated with each other? Another important reason why feature branches are so useful is that they allow to postpone the decision about integration of some feature to the master branch to the time when you convince that it is ready and useful. In a "centralized" workflow, people often commit as they progress to their goal, but some ideas may not so good as they initially appeared. At the time when you realize that, your changes already intervened with other people changes. There is no easy way to remove them cleanly. And, some work even if it is useful may be not ready to the time when you planned to realize a new version. This results in unnecessary delays in release. There are more problems with the "centralized" workflow used by CVS and alike. They may be not very noticeable on small projects, but it tends to get worse as any project growths over time. So, the main advantage of Git is not in the number of features (and Git has plenty of them despite of efforts to limit them to only truly useful for many users), but its conceptual wholeness and flexibility, which allows you to choose the appropriate workflow for your needs. Dmitry -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html