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 Subject: Re: On the subject of Git, Bazaar, and the future of Emacs development Date: Thu, 28 Mar 2013 12:26:33 +0900 Message-ID: <87ehf0b3x2.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87y5d9p5td.fsf@dex.adm.naquadah.org> <87vc8dtbcb.fsf@lifelogs.com> <871ub1gmdf.fsf@engster.org> <87d2ulovd0.fsf@dex.adm.naquadah.org> <85r4j0h1ww.fsf@member.fsf.org> <85li98h1qx.fsf@member.fsf.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1364441206 28309 80.91.229.3 (28 Mar 2013 03:26:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Mar 2013 03:26:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 28 04:27:12 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UL3UY-0002CY-Ee for ged-emacs-devel@m.gmane.org; Thu, 28 Mar 2013 04:27:06 +0100 Original-Received: from localhost ([::1]:38918 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL3UA-0000E7-9C for ged-emacs-devel@m.gmane.org; Wed, 27 Mar 2013 23:26:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL3U5-0000De-R3 for emacs-devel@gnu.org; Wed, 27 Mar 2013 23:26:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UL3U4-0008VV-KQ for emacs-devel@gnu.org; Wed, 27 Mar 2013 23:26:37 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:34853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL3U4-0008V4-30 for emacs-devel@gnu.org; Wed, 27 Mar 2013 23:26:36 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id E7A5C970860; Thu, 28 Mar 2013 12:26:33 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id ABAAF1A3D97; Thu, 28 Mar 2013 12:26:33 +0900 (JST) In-Reply-To: <85li98h1qx.fsf@member.fsf.org> X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:158333 Archived-At: Stephen Leake writes: > If I understand what you mean by "bidirectional merging", then monotone > handles it nicely (http://www.monotone.ca/). > > I use monotone for all my projects, and merge back and forth between > branches all the time. When you say "my", do you mean projects that mostly only you work on? If so, you probably won't run into the problem, unless you're in the habit of keeping several workspaces on a given branch and you don't keep them current. In a one-person, multibranch workflow, you will typically see DAGs like this: trunk 0--------A--B--C--D-- ... \ / \ \ / \ branch a--b--c--------d-- ... and the nature of such workflows is that typically conflicts are relatively few; you do different things in different branches. Furthermore, at each merge point ( and ) there are exactly two paths from the most recent common ancestor ( and , respectively), which helps to simplify analysis of the merge. Multi-person, multi-branch workflows admit a nastier kind of geometry, which the Bazaar developers call "criss-cross merges" for an obvious reason: trunk 0--------A--B--C--D--E----- ... \ / \/ \ \ / /\ \ branch a--b--c-----d--e-----f-- ... and the merge at can be a monstrosity because the structure of the DAG is little help in disentangling conflicts: the most recent common ancestor of is , and there are 4 "long" paths between them, increasing the expected number of conflicts. If Monotone does handle these gracefully, that would be *really* cool! > I suspect the key feature that makes it work is the conflict > resolution tools in monotone; > http://www.monotone.ca/docs/Merge-Conflicts.html#Merge-Conflicts Could be, but I really don't see anything on that page that other DVCSes don't have, and the note about "the special case of file content conflicts" which invoke an external merge tool looks pretty ordinary. I suspect that --resolve-conflicts-file does something similar to git's rerere command, or perhaps git's interactive rebase command. Steve