Am 31.01.2013 um 10:36 schrieb Frank Shearar <frank.shearar at gmail.com>:

> On 31 January 2013 06:31, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> 
>> Am 30.01.2013 um 19:50 schrieb Frank Shearar <frank.shearar at gmail.com>:
>> 
>>> On 30 January 2013 18:33,  <commits at source.squeak.org> wrote:
>>> 
>>> <snip>
>>> 
>>> Diffs serve as a helper for reviewers. To that end, the diffs ought to
>>> actually show what changes would be applied to trunk should the change
>>> be accepted. This diff, for instance, shows the removal of
>>> #asMessageSend and the addition of #asMessage, but really the change
>>> applied to trunk will be just the addition of #asMessage.
>>> 
>>> In other words when something undergoes a few rounds of review (and
>>> I'd think this should be the _norm_) the reviewer must reconstruct a
>>> series of diffs to get an idea of how trunk will change.
>>> 
>>> Wouldn't it be better to diff against trunk rather than against the
>>> mcz's ancestor? (*)
>>> 
>>> frank
>> 
>> You should move obsolete versions out of the inbox. The diff is against the latest ancestor in inbox or trunk.
> 
> OK, but if we do that then we lose ancestry. I know what you're
> hinting at, and I'd also like to see the equivalent of a git squash -
> "take these versions in this branch and squish them together so that
> the main line only sees a single commit".

What about the "adopt ancestor" option of monticello?
This would neatly allow this.

BEst
	-Tobias

> Right now that's pretty
> onerous: it'd be a manual task, fraught with opportunities to mess up.
> Er, actually, am I talking nonsense? Given some series of mczs, once
> the chain/latest has passed peer review, I could
> 
> * load the latest versions into a clean up-to-date image
> * file out the versions (so we flush the ancestry)
> * load the fileouts into a clean up-to-date image
> * commit to trunk, with suitable commit messages.
> 
> That's nearly automatable, except for the commit messages.
> 
>> We could change that to prefer trunk over inbox as diff base, agreed. Care to submit a squeaksource patch? :)
> 
> *ahem*. OK - that's http://source.squeak.org/SqueakSource-SqF/ right?

and http://www.squeaksource.com/squeaksource3 
*tongueincheek*
;)

Best
	-Tobias