Re: Latest merge from the emacs-23 branch

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Okay, then how about including with the merge commit message the list
> of revisions you backed out after merging?  This list cannot be too
> long (otherwise merging doesn't make sense).

Actually, the list can be any length and the merge would still make
sense, because the merge of changes we actually don't want is performed
to make future merges easier (and to keep track of the fact that we
already did what we had to do with these changes (i.e. "not merge it")).

In practice the list tends to be reasonably short (since it only
includes things like backports plus a few changes that are already
overridden on the trunk, like changing the release number).  So we could
probably include it, tho it's more work.  Currently, the output that my
script gets doesn't mention revision ids, only revision numbers and log
messages, so maybe we could just include the first line of commit
messages instead of revision ids.

>> > No, there actually seem to be 2 different revisions on the trunk now that
>> > appear to solve the same issue in two different ways.  For example, this
>> > "merge":
>> >  99634.2.670: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs
>> > is also present here:
>> >  102637: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs
>> Yup.  This is a non-issue.
> It will be a non-issue if there's a way to know that 99634.2.670 was
> reverse cherry-picked after merging.  Otherwise, how can I distinguish
> between this case and the case of erroneously merging from the branch
> (which happened in the past)?

By looking at the code.  Even with more metadata, only the code can tell
you what was actually changed since the metadata can only tell you what
bzr commands were used (and even that only to a limited extent since my
script uses various ways to cheat around bzr's limitations), but not how
conflicts were resolved manually or what extra manual changes
were performed.


        Stefan