From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "David Allouche" Newsgroups: gmane.comp.version-control.bazaar-ng.general,gmane.emacs.devel Subject: Re: Emacs Bazaar repository Date: Fri, 14 Mar 2008 16:15:51 +0100 Message-ID: References: <87skyvse7k.fsf@xmission.com> <86ejae96t4.fsf@lola.quinscape.zz> <47DA3601.3040507@arbash-meinel.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1205507787 27533 80.91.229.12 (14 Mar 2008 15:16:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2008 15:16:27 +0000 (UTC) Cc: bazaar@lists.canonical.com, Eli Zaretskii , dak@gnu.org, Matthieu Moy , emacs-devel@gnu.org To: "Andreas Schwab" Original-X-From: bazaar-bounces@lists.canonical.com Fri Mar 14 16:16:55 2008 Return-path: Envelope-to: gcvbg-bazaar-ng@m.gmane.org Original-Received: from chlorine.canonical.com ([91.189.94.204]) by lo.gmane.org with esmtp (Exim 4.50) id 1JaBe6-0006s7-4G for gcvbg-bazaar-ng@m.gmane.org; Fri, 14 Mar 2008 16:16:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.60) (envelope-from ) id 1JaBdW-0005rW-0R; Fri, 14 Mar 2008 15:15:58 +0000 Original-Received: from el-out-1112.google.com ([209.85.162.176]) by chlorine.canonical.com with esmtp (Exim 4.60) (envelope-from ) id 1JaBdQ-0005r0-Vb for bazaar@lists.canonical.com; Fri, 14 Mar 2008 15:15:53 +0000 Original-Received: by el-out-1112.google.com with SMTP id s27so2173442ele.18 for ; Fri, 14 Mar 2008 08:15:52 -0700 (PDT) Original-Received: by 10.142.240.9 with SMTP id n9mr4983964wfh.214.1205507751492; Fri, 14 Mar 2008 08:15:51 -0700 (PDT) Original-Received: by 10.142.170.14 with HTTP; Fri, 14 Mar 2008 08:15:51 -0700 (PDT) In-Reply-To: Content-Disposition: inline X-Google-Sender-Auth: 314cca6eba2ecb29 X-BeenThere: bazaar@lists.canonical.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: bazaar discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bazaar-bounces@lists.canonical.com Errors-To: bazaar-bounces@lists.canonical.com Xref: news.gmane.org gmane.comp.version-control.bazaar-ng.general:38586 gmane.emacs.devel:92574 Archived-At: On Fri, Mar 14, 2008 at 3:30 PM, Andreas Schwab wrote: > Matthieu Moy writes: > > > As opposed to that, bzr makes the distinction between "mainline > > revisions" (that you commited in the branch), and merged revisions > > (ancestors of merge commits that you brought here with a merge). > > Is that a useful distinction? I think git treats all branches equal, > there is no "mainline". Bzr also treats all branches as equal. There is no "mainline branch" the tool knows of. But there are "mainline revisions" in the ancestry of a given revision (or branch tip). > If you merge two branches that touch different > parts of the tree there is no need to distinguish the two threads. In bzr, the mainline ancestry of a revision is the transitive closure of the leftmost parent. The mainline ancestry is considered important because it records the sequence of commits that occured on a given branch. It gives a better view of the intent of the committer. For example, a revision with the message "merge from trunk" usually means "take in whatever got in the trunk", not "merge feature a, bugfix b, cleanup c, refactoring d, and 43 other equally crucial changes". Most merges do not reflect essential work that occured on the branch. On the other hand, the mainline commits usually capture the essential work that occured on a branch. By distinguishing them, bzr makes it easier to read the history of a branch. > > That's a real difference in the way git and bzr deal with the history > > DAG, not just about "log". For example, git merge defaults to > > fast-forward (i.e. if you merge a revision you are a direct ancestor > > of, you just jump to that revision without creating a new commit). > > If you just move forward in the history it is not really a merge, so > there should not be a need for creating a marker for it. You can do fast forward in bzr with "pull". Merge behave differently because we consider that "merge" _as a task_ has a different meaning _to the user_ than pull. Typically, a gatekeeper only merges, then run the test suite, and only commit if the test suite pass. The gatekeeper's branch mainline history will only contain revisions that passed the test suite. The way you make it sound, the git approach is "if we can get the same result by fast forward, we do not need a new commit". The bzr approach is that a new commit provides important historical information regardless.