On Wed, Oct 18, 2006 at 12:31:52PM -0400, Aaron Bentley wrote:

quoted text
> -----BEGIN PGP SIGNED MESSAGE-----

> Hash: SHA1

>

> Jakub Narebski wrote:

> > Aaron Bentley wrote:

> >

> >>Carl Worth wrote:

> >>>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.

> >

> >

> > But what patch reviewer see is a mega-patch showing the changeset

> > of a whole "bundle", isn't it?

> > [...]

>

> Yes.  Carl was saying that, aside from the issue of what a reviewer

> sees, a bundle is bad for other reasons.  I am saying those other

> reasons don't apply.  I wasn't addressing the issue of what a reviewer sees.

>

> To me, seeing the individual patches is like reading a book where every

> page has a different word on it, and so it's hard to put it together

> into a full sentence.  I'm not saying my way is The Right Way, just my

> personal preference.

>

> For larger pieces of work, we try to split them up into logical units,

> and merge those units independently.

>

> The Bundle format can also support a patch-by-patch output, but we don't

> have UI to select that.

As for what the reviewer wants to see, I think it depends on what kind

of code it is. Kernel code is complex and does not have (at least I have

not heared of) unit-tests, so short patches are preferable for review.

And since C is of the more verbose languages, short patches mean

spliting them up into several pieces.
On the other hand bzr has unit-tests and python is less verbose, so the

single patch for a feature is not so big and is manageable. The patches

to bzr still come in logical steps, but usually one step per feature is

enough.
Also programmers usually don't develop even the single logical step as a

single commit. Instead they they also commit to backup their work,

when they try something they think they may in future return, when they

need to continue on another computer and so on. And these commits are

generally not logical steps. Also the steps are often not in a logical

order. Therefore showing diff for each commit in the bundle often does

not make sense.
So there is one bundle per logical step and therefore has a summary

diff. Individual bundles for individual steps are preferable anyway,

since the maintainer may decide to accept just some of them.  A tool to

generate a series of bundles (either each with just one commit or each

with several commits) would be possible, just noone was interested

enough to do it yet.
--------------------------------------------------------------------------------

                  				- Jan Hudec `Bulb'

-

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