[MERGE REVIEW] Tweaks to bundle merging

[Michael Ellerman]

On 6/18/06, John Arbash Meinel <john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Ellerman wrote:
> > On 6/16/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Michael Ellerman wrote:
> >> > Come to think of it, why do we need the roll-up diff at all? Aren't
> >> > all the individual diffs sufficient?
> >>
> >> No, the roll-up contains the data to produce the target revision, which
> >> none of the other diffs contains.
> >>
> >> 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.
> >
> > 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.
> >
> >> 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.
> >
> > cheers
> >
> >
>
> The biggest thing is that with a rollup, you may revert some changes in
> a later hunk than what shows in a previous hunk. Which is much harder to
> review than just the final patch.

Ah yeah good point. I'm used to a culture where you only push changes
that are self-contained and perfect, so hiding false starts isn't an
issue.

On the one hand I can see that it's nice to be able to correct stuff
and just send the cleaned-up diff to the list. At the same time having
all the individual diffs out for display will encourage people to get
it right first time.

Only displaying the roll-up also exposes you to the risk that someone
will send you a bundle that adds something rude/controversial/libelous
to the tree, then removes it in the next commit and you never see it
until it's committed to the repository. Although admittedly that's
unlikely one would hope.

cheers