Re: Git drawbacks?

From: Dmitry Smirnov <divis1969@gmail.com>
Date: Nov 10, 2009, 08:51 UTC
Message-ID: <loom.20091110T093334-810@post.gmane.org>
In-Reply-To: <20091109210631.GJ27126@dpotapov.dyndns.org>

Dmitry Potapov <dpotapov <at> gmail.com> writes:

Show 6 quoted lines

> With many other VCS, a typical policy is that you do not commit your
> changes unless you have finished and tested them. But it means that
> your changes are not committed and stored only in the work tree for
> a long time. Moreover, when you eventually decide that they are good
> enough to commit, you will produce a huge patch, which will be difficult
> to review or to bisect history later.

oh, yes. but this is just a policy. You can make your changes on your 
branch and commit them (for example, for review). Later someone just 
need to integrate it on original branch. The same as with Git, 
isn't it? The problem is just a price to branch.
BTW, once I started to talk about review, we can see that most 
"benefits" of DVCS go away... Just because you still need some 
central storage to save the record of this review that should 
be available for SQA later...

Show 7 quoted lines

> So, you can always commit your changes as your progress to your goal and
> review amend them later before publishing. This means that you can have
> as many work-in-progress branches as you wish, and you do not need a
> separate work tree for each of them -- everything can be stored in the
> repository, and you can go to another computer, issue 'git fetch' and
> continue your work at the exact point where you left it. So, it is very
> flexible.

As for me, I would not to have more than 4-5 such deferred changes in the same repository. Otherwise, I will be entangled finally :-)