From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel,gmane.comp.version-control.bazaar-ng.general Subject: Re: Emacs Bazaar repository Date: Sat, 15 Mar 2008 09:39:52 +0900 Message-ID: <87od9gstuv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87skyvse7k.fsf@xmission.com> <86ejae96t4.fsf@lola.quinscape.zz> <47DA3601.3040507@arbash-meinel.com> <85d4px4edd.fsf@lola.goethe.zz> <1205502278.6161.398.camel@flash> <857ig54dak.fsf@lola.goethe.zz> <1205503781.6161.405.camel@flash> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205541114 12658 80.91.229.12 (15 Mar 2008 00:31:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Mar 2008 00:31:54 +0000 (UTC) Cc: bazaar@lists.canonical.com, John Arbash Meinel , Matthieu Moy , schwab@suse.de, emacs-devel@gnu.org, Eli Zaretskii To: James Westby Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 15 01:32:20 2008 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 1JaKJv-0007g4-Hs for ged-emacs-devel@m.gmane.org; Sat, 15 Mar 2008 01:32:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaKJM-000655-2Z for ged-emacs-devel@m.gmane.org; Fri, 14 Mar 2008 20:31:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JaKJI-00063U-Ka for emacs-devel@gnu.org; Fri, 14 Mar 2008 20:31:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JaKJH-00062m-Sr for emacs-devel@gnu.org; Fri, 14 Mar 2008 20:31:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaKJH-00062U-Mt for emacs-devel@gnu.org; Fri, 14 Mar 2008 20:31:39 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JaKJ9-0002WI-So; Fri, 14 Mar 2008 20:31:32 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 6E8F11535A8; Sat, 15 Mar 2008 09:31:29 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AB1CC1A29EF; Sat, 15 Mar 2008 09:39:52 +0900 (JST) In-Reply-To: <1205503781.6161.405.camel@flash> X-Mailer: VM 7.19 under 21.5 (beta28) "fuki" 2785829fe37c XEmacs Lucid X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:92637 gmane.comp.version-control.bazaar-ng.general:38631 Archived-At: James Westby writes: > May I point you to my blog post of yesterday that explains some of > these issues, rather than spell if all out here? > > http://jameswestby.net/weblog/bzr/01-revision-numbers.html > > The last section is on this particular issue. > > The gist of it is that topological sorting means that children appear > before their parents. bzr does "merge sorting" that ensures that a > revision does not appear after a revision that it is not an ancestor > of. Excuse me? There may be something sensible you wish to say, but what I have quoted is not it. If A and B are not ordered by ancestry both "AB" and "BA" fail to be a "merge sort" according to that criterion. >From the blog: Always having merge commits means that "bzr log --short" and "bzr log --line" can give you a good summary of what happened on your branch, the commits you did, and the things that you merged. It preserves a mainline for you in the left hand ancestry, git-show-branch does this satisfactorily for me, although admittedly more recent unmerged commits on other branches may show up first. This is a *good* thing if I'm thinking about merging them, though. OTOH, gitk simply prunes any unmerged commits by default. How does "merge sort" differ from "topological sort pruning unmerged commits"? AFAICT in that case "not an ancestor" == "is a descendant" so topo sort and merge sort are the same. What am I missing? The indentation of the merged commits (and the fact they disappear with "--short" and "--line") means that mentally they become of lesser importance. But that's exactly what I rarely want. I know what I did, unless it was a long time ago. What I generally want to know is what others are doing, and how that impacts my branch when I merge their code. > While we may be able to offer some UI improvements to git itself there > may be fundamental differences that mean git may always fall short of > what we would like. There are also things that bzr can do that git > will never do (barring any big changes in direction), for instance > foreign branch support. What is "foreign branch support", and why do you think that a program which is amounts to being a browser for the universal revision graph can't do it? An URL would do.