On Wed, Oct 18, 2006 at 12:31:52PM -0400, Aaron Bentley wrote:
> -----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' <bulb@xxxxxx>
-
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