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: Sun, 19 Dec 2010 08:47:18 -0500 Message-ID: References: <83zks4fkua.fsf@gnu.org> <83sjxwf18y.fsf@gnu.org> <83hbebf0dd.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1292766452 7498 80.91.229.12 (19 Dec 2010 13:47:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 19 Dec 2010 13:47: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 Sun Dec 19 14:47:28 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 1PUJbj-0007VT-Oq for ged-emacs-devel@m.gmane.org; Sun, 19 Dec 2010 14:47:27 +0100 Original-Received: from localhost ([127.0.0.1]:50792 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PUJbj-0004gK-9n for ged-emacs-devel@m.gmane.org; Sun, 19 Dec 2010 08:47:27 -0500 Original-Received: from [140.186.70.92] (port=35371 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PUJbe-0004gD-V5 for emacs-devel@gnu.org; Sun, 19 Dec 2010 08:47:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PUJbd-0007wd-5q for emacs-devel@gnu.org; Sun, 19 Dec 2010 08:47:22 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:15709 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PUJbb-0007w9-Rx; Sun, 19 Dec 2010 08:47:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO6bDU1Ld/KP/2dsb2JhbACkM3S6ZoVKBIRljhI X-IronPort-AV: E=Sophos;i="4.60,196,1291611600"; d="scan'208";a="85871417" 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; 19 Dec 2010 08:47:18 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 59F1058E99; Sun, 19 Dec 2010 08:47:18 -0500 (EST) In-Reply-To: <83hbebf0dd.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 Dec 2010 19:37:34 +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:133811 Archived-At: > 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