From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: log format for vc-bzr Date: Tue, 08 Dec 2009 20:19:02 +0100 Message-ID: <874oo1w9y1.fsf@telefonica.net> References: <200912081747.nB8HlwPR021836@godzilla.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1260300628 12941 80.91.229.12 (8 Dec 2009 19:30:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Dec 2009 19:30:28 +0000 (UTC) Cc: Dan Nicolaescu To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 08 20:30:21 2009 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.50) id 1NI5ky-0007VU-IR for ged-emacs-devel@m.gmane.org; Tue, 08 Dec 2009 20:29:56 +0100 Original-Received: from localhost ([127.0.0.1]:42198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NI5ky-0002yF-Cb for ged-emacs-devel@m.gmane.org; Tue, 08 Dec 2009 14:29:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NI5au-0000eq-IR for emacs-devel@gnu.org; Tue, 08 Dec 2009 14:19:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NI5ap-0000ZK-TA for emacs-devel@gnu.org; Tue, 08 Dec 2009 14:19:31 -0500 Original-Received: from [199.232.76.173] (port=48998 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NI5ap-0000Yz-BD for emacs-devel@gnu.org; Tue, 08 Dec 2009 14:19:27 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:43414) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NI5ap-0006CC-9c for emacs-devel@gnu.org; Tue, 08 Dec 2009 14:19:27 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NI5aj-0001qz-Qm for emacs-devel@gnu.org; Tue, 08 Dec 2009 20:19:21 +0100 Original-Received: from 64.red-83-34-21.dynamicip.rima-tde.net ([83.34.21.64]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Dec 2009 20:19:21 +0100 Original-Received: from ofv by 64.red-83-34-21.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Dec 2009 20:19:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 62 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 64.red-83-34-21.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:0EoPISfYETEtaS8pYhtPbjX/bo8= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:118395 Archived-At: Dan Nicolaescu writes: > The default C-x v l format for bzr does not show merges. > > The default C-x v g format shows the version number from the merge: > Here's an example from bzr itself: > > > | from cStringIO import StringIO > 0.16.5 aaron@a | import shutil > 0.16.1 aaron@a | import sys > 0.16.5 aaron@a | import tempfile > 0.16.1 aaron@a | > 0.16.25 aaron@a | from bzrlib import ( > | builtins, > | delta, > | diff, > | errors, > 0.16.79 aaron@a | osutils, > 0.16.25 aaron@a | patches, > 0.16.74 aaron@a | shelf, > 0.16.72 aaron@a | textfile, > 0.16.54 aaron@a | trace, > 0.16.64 aaron@a | ui, > 0.16.102 aaron@a | workingtree, > > The result is that when using the "l" key binding in vc-annotate emacs > is not able to find the log for the revision mentioned in the annotate > buffer. > > This can be solved by passing the "--include-merges" to "bzr log". > Any reason not to do that? With the distributed development style that encourages committing often, the history that comes from the merged branch can be very boring and irrelevant. Something like this: 15.23 gone lunch 15.24 some refactoring 15.25 seems ready for testing The important info is in the merge commit: 15 Added feature Foo and that is what the log should show by default. OTOH, for long-lived merged branches that implements complex features, the merged history conveys useful information. So, in the best Emacs tradition, both modes should be supported :-) Personally, I'm against showing the merged history by default. If you need to pass --include-merges for showing a merged commit, that's okay, but not when the user asks for the log with C-x v l. It would be interesting to have a method on the log buffer for showing the merged history at some merge point. Some kind of "expand this one level". -- Óscar