-----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. > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html