From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Confusing "bzr log" as result of merges Date: Mon, 23 May 2011 08:58:18 -0400 Message-ID: References: <83ipt4fqyy.fsf@gnu.org> <83lixyejbv.fsf@gnu.org> <83ipt2dssn.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1306155513 3344 80.91.229.12 (23 May 2011 12:58:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 May 2011 12:58:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 23 14:58:29 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QOUiG-0003rn-AD for ged-emacs-devel@m.gmane.org; Mon, 23 May 2011 14:58:24 +0200 Original-Received: from localhost ([::1]:44908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOUiF-0006jQ-0a for ged-emacs-devel@m.gmane.org; Mon, 23 May 2011 08:58:23 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOUiC-0006jK-9a for emacs-devel@gnu.org; Mon, 23 May 2011 08:58:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOUiB-00063j-A6 for emacs-devel@gnu.org; Mon, 23 May 2011 08:58:20 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:35858) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOUiB-00063f-7T for emacs-devel@gnu.org; Mon, 23 May 2011 08:58:19 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QOUiA-0000Ws-P9; Mon, 23 May 2011 08:58:18 -0400 In-reply-to: (message from Stefan Monnier on Mon, 23 May 2011 09:02:37 -0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139641 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Mon, 23 May 2011 09:02:37 -0300 > > >> > tool. The discrepancy here happens because bzrmerge.el plays unholy > >> > games with the metadata as opposed to the sources. If we need to do > >> You are confused: the metadata resulting from bzrmerge.el is 100% > >> identical to the metadata resulting from "bzr merge". > > I don't think I'm confused that much: I said "metadata as opposed to > > the sources". > > Merging with bzrmerge.el instead of with "bzr merge" should result in > an absolutely identical result, except for the fact that the guy doing > the merge will have to do a bit less work. The problem is not that we are merging, but that we merge revisions we don't need. We then revert the effect of the merge in the sources, but the metadata "remembers" that the reverted revision is in the trunk. Doing the same manually will obviously produce the same result, but my point was why do it at all. IOW, I'm not saying that bzrmerge.el is the culprit. I'm saying that the method we use to merge from emacs-23 (which is implemented by bzrmerge.el) is the culprit.