On Wed, Jul 22, 2009 at 3:07 PM, Dmitry Potapov<dpotapov@xxxxxxxxx> wrote: > 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 > I agree whole heartedly with you that git is the best SCM in town. It's my favorite, and I completely agree that CVS and SVN are fundamentally flawed in how they implement branches. I'm not looking for why you should choose git over another tool :) Let me rephrase the question: :: QUESTION REPHRASED :: Out of the shoot, you get a lot of value learning the basic features of git: easy branching, merging, etc. How has learning the advanced features of git (bisect, rebase, rebase -i, add -p, etc.) helped you to write software more effectively? -- 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