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: Sun, 22 May 2011 20:28:04 +0300 Message-ID: <83lixyejbv.fsf@gnu.org> References: <83ipt4fqyy.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1306085293 29502 80.91.229.12 (22 May 2011 17:28:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 22 May 2011 17:28:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 22 19:28:09 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 1QOCRk-0000Ka-0d for ged-emacs-devel@m.gmane.org; Sun, 22 May 2011 19:28:08 +0200 Original-Received: from localhost ([::1]:52367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOCRi-0007G2-Qx for ged-emacs-devel@m.gmane.org; Sun, 22 May 2011 13:28:06 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52155) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOCRg-0007Fx-2z for emacs-devel@gnu.org; Sun, 22 May 2011 13:28:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOCRf-0001gH-3m for emacs-devel@gnu.org; Sun, 22 May 2011 13:28:04 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:57989) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOCRe-0001g8-Pr for emacs-devel@gnu.org; Sun, 22 May 2011 13:28:03 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LLL00800XRMI000@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sun, 22 May 2011 20:28:00 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.124.254.13]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LLL007N4XUMWE70@a-mtaout22.012.net.il>; Sun, 22 May 2011 20:28:00 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:139625 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Sun, 22 May 2011 11:14:40 -0300 > > > With the current trunk, type this command: > > bzr log -l1 --line --include-merges src/xdisp.c > > You will see this as output: > > 104201: Glenn Morris 2011-05-12 [merge] Merge from emacs-23; up to r100577. > > However, neither "bzr status" nor "bzr diff" will show any changes for > > xdisp.c in that revision. The reason, it seems, is this: > [...] > > What can we do to avoid this confusion as result of merges? > > Easy: if it hurts, don't do it. ??? You mean, don't use one of the most useful and efficient commands in bzr? > The log command you used does not tell you "the latest revision that > changed src/xdisp.c" It does, in all other circumstances. It just goes by the metadata, not by source lines. > so if you're looking for this latest revision, use something else, > like bzr annotate. "bzr annotate" is dog slow, especially on a long and veteran file such as xdisp.c, even if you limit the range of revisions you ask it to display. "bzr log", by contrast, is very fast (unless you go fancy about how you select revisions, e.g. with "-r annotate:"). Guess what I prefer first and foremost. You consistently dismiss complaints in this area for reasons I cannot understand. Just because you don't need these tools does not yet mean they aren't important for others. I need them a lot while hacking the display engine, because there's no one here who can help me understand why a particular piece of code was written; by digging into the history and finding out who committed it and when, I can most of the time find the answers and DTRT. But these complications are a huge time drain for me. Some of them are probably water under the bridge, because of the way the CVS repository was converted to Bazaar (I guess the limited testing done back then was not thorough enough), but others can be avoided. > The same kind of problems will show up with many other merges. > The problem is not in the way those branches were handled or how the > merge was done: the problem is that the request you use will not tell > you quite what you're looking for (although it may occasionally do). I don't agree. In general, all the possible ways of asking something should give you the same answer, otherwise you cannot really trust the tool. The discrepancy here happens because bzrmerge.el plays unholy games with the metadata as opposed to the sources. If we need to do this, let's do it on the branch, as others suggested, not on the trunk. Alternatively, we could apply to the trunk changes from the branch as simple diffs, with Patch. I don't see how any of these two alternatives are worse or harder than what we currently have.