From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Latest merge from the emacs-23 branch Date: Sat, 18 Dec 2010 10:58:14 -0500 Message-ID: References: <83zks4fkua.fsf@gnu.org> <83sjxwf18y.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1292687912 17594 80.91.229.12 (18 Dec 2010 15:58:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 18 Dec 2010 15:58:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 18 16:58:25 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PTzAu-0002pu-9H for ged-emacs-devel@m.gmane.org; Sat, 18 Dec 2010 16:58:24 +0100 Original-Received: from localhost ([127.0.0.1]:45923 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PTzAt-0004me-C8 for ged-emacs-devel@m.gmane.org; Sat, 18 Dec 2010 10:58:23 -0500 Original-Received: from [140.186.70.92] (port=59740 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PTzAo-0004mK-0k for emacs-devel@gnu.org; Sat, 18 Dec 2010 10:58:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PTzAm-0006Ir-Up for emacs-devel@gnu.org; Sat, 18 Dec 2010 10:58:17 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:11998 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PTzAl-0006IB-Nu; Sat, 18 Dec 2010 10:58:15 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANhoDE1Ld/KP/2dsb2JhbACkNHS8RIVKBIRljhI X-IronPort-AV: E=Sophos;i="4.60,194,1291611600"; d="scan'208";a="85811767" Original-Received: from 75-119-242-143.dsl.teksavvy.com (HELO pastel.home) ([75.119.242.143]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 18 Dec 2010 10:58:14 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id A048A58E99; Sat, 18 Dec 2010 10:58:14 -0500 (EST) In-Reply-To: <83sjxwf18y.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 Dec 2010 01:06:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133792 Archived-At: >> 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