Subject: Re: VCS comparison table

From: Aaron Bentley <[email-masked]>
Date: Tue, 17 Oct 2006 23:27:50 -0400

Carl Worth wrote:
> On Wed, 18 Oct 2006 03:28:30 +0200, Jakub Narebski wrote:
>> Isn't it easier to review than "bundle", aka. mega-patch?
> 
> There are even more important reasons to prefer a series of
> micro-commits over a mega-patch than just ease of merging.

A bundle isn't a mega-patch.  It contains all the source revisions.  So
when you merge or pull it, you get all the original revisions in your
repository.

> We have great tools like bisect to identify commits that introduce
> bugs. I know that I'd be delighted to see bisect comes back pointing
> at some minimal commit as causing a bug, (which would make finding the
> bug so much easier).

Bisect should work equally well with revisions pulled or merged from a
bundle as revisions re-committed from patches.

> But it's also been my experience that the largest commits are also the
> most likely to be the things returned by bisect. Big commits really do
> introduce bugs more frequently than small commits.

The number of changes shown in the diff has nothing to do with the
number of changes made per commit.

> Now, I do admit that it is often useful to take the overall view of a
> patch series being submitted. This is often the case when a patch
> series is in some sub-module of the code for which I don't have as
> much direct involvement. In cases like that I will often do review
> only of the diff between the tips of the mainline and the branch of
> interest, (or if I trust the maintainer enough, perhaps just the
> diffstat between the two). But I'm still very glad that what lands in
> the history is the series of independent changes, and not one mega
> commit.

So the difference here is that bundles preserve the original commits the
changes came from, so even though it's presented as an overview, you
still have a series of independent changes in your history.

Aaron