emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Latest merge from the emacs-23 branch


From: Stefan Monnier
Subject: Re: Latest merge from the emacs-23 branch
Date: Sat, 18 Dec 2010 10:58:14 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>> 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.  E.g. CVS did not do it and this is one of the main reasons
why I've pushed to change VCS.  When we want to add the content of one
branch to another, we need to know that history in order to know which
part of the branch still needs to be added.  As long as we do "whole
branch merges", Bazaar keeps track of it for us.  If we start doing it
piecewise, Bazaar doesn't know how to do it for us, so we'd have to do
it by hand.  We used to do it by hand with CVS, but we did it for "whole
branch merges", which is the easy case (so easy that even Bazaar can do
it for us)., doing it on a revision-by-revision basis is a lot
more troublesome.

>> I'm not sure what you mean by "some of them are not actually
>> included in the merge", tho.  AFAIK they are included in the sense
>> that the corresponding change is now present on the trunk.

> 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.

> Reading such log messages will result in a lot of confusion, I'm
> afraid.

Time will tell if your fear is justified.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]