-----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.
> I think it is much better to review series of patches commit by commit;

quoted text
> 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

quoted text
> 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