[MERGE REVIEW] Tweaks to bundle merging

Aaron Bentley aaron.bentley at utoronto.ca
Sat Jun 17 15:50:21 BST 2006

Hash: SHA1

Michael Ellerman wrote:
> On 6/16/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
>> It doesn't have to be a roll-up, though-- it could be just like the
>> other diffs.  We made it a roll-up so that you could review the combined
>> changes using it.
> Yeah, that's what I meant, show each diff individually. That has the
> other nice property that the messages correspond to the diff hunks.

Personally, I prefer to see all the changes at once.  I don't want to
see all the false starts and reverted changes.  What I want to see is
what the bundle will do to a tree if I merge it.

> I think this would work even better if all the trailing blocks
> (revision_id/sha1/etc) could drop to the bottom. And maybe be
> base64'ed there too.

I do find it nice to see all the commit messages (contradicting my first
point a bit), but the bottoms mostly aren't useful, I agree.  Except
that I can guess whether the bundle will apply by looking at its base

>> Plus it means that we can check the target revision's signature without
>> having to install anything.
> Ok, that's nice I guess. But not sure if it justifies the slight
> strangness of the current format.

It wasn't planned, but I think it's very useful for submit-by-email and
things.  The main reason was because the roll-up's more interesting than
the series of patches that produce it.

The format is flexible, though.  A bundle that didn't have any roll-ups
would still be valid.

Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list