[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: How has learning the advanced features of git helped you to write
From:       Tim Harper <timcharper () gmail ! com>
Date:       2009-07-22 21:21:26
Message-ID: e1a5e9a00907221421m27f0f836t98d361dffc7bd87f () mail ! gmail ! com
[Download RAW message or body]

On Wed, Jul 22, 2009 at 3:07 PM, Dmitry Potapov<dpotapov@gmail.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]