Re: Latest merge from the emacs-23 branch

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sat, 18 Dec 2010 10:58:14 -0500
> 
> >> Cherrypicking is unworkable since it means doing all the
> >> history-tracking by hand.
> > What do you mean by "history-tracking", and why do we need to do it by
> > hand?
> 
> By history tracking I mean keeping track of what has been merged where
> and when.

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).  Until now we only had a
laconic "merge from emacs-23" as the log message.

> > 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)?