-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jakub Narebski wrote:
quoted text
> 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.

quoted text
> I think it is much better to review series of patches commit by commit;
> besides it allows to correct some inner patches before applying the whole
> series or drop one of patches in series (and it happened from time to time
> on git mailing list).

It's important to remember that bundles represent revisions, not
patches.  When you merge a bundle, you

1. install those revisions into your repository.  These revisions are
   latent, as though they were on another branch.
2. merge the head revision of the bundle into your branch.

Virtually any merge selection process that works with branches would
also work with bundles.  So tweaking before merging is really a matter
of replacing the UI for 2.

quoted text
> So if git introduces bundles, I think they would take form of series
> of "patch" mails + introductory email with series description (currently
> it is not saved anywhere), shortlog, diffstat and perhaps more metainfo
> like bundle parent (which I think should be email form of branch really),
> tags introduced etc.

The parent in a bundle revision is the revision-id of the parent of that
revision in the branch.  I don't think it's possible to change that
parent id into something else, without changing the meaning of a bundle.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFNlb40F+nu1YWqI0RAnxxAJ9ETibey1Qyvz/zVxdGipaHGtnddgCfTtzt
CQUZ2dK64BS5K5WYecFAsfM=
=bJxq
-----END PGP SIGNATURE-----
-
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