From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: On the subject of Git, Bazaar, and the future of Emacs development Date: Thu, 28 Mar 2013 04:37:58 -0400 Message-ID: <85y5d7gbrt.fsf@member.fsf.org> 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> <87ehf0b3x2.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1364459915 15397 80.91.229.3 (28 Mar 2013 08:38:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Mar 2013 08:38:35 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 28 09:39:02 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 1UL8MM-0005tu-VJ for ged-emacs-devel@m.gmane.org; Thu, 28 Mar 2013 09:38:59 +0100 Original-Received: from localhost ([::1]:38411 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL8Ly-0006p2-Sv for ged-emacs-devel@m.gmane.org; Thu, 28 Mar 2013 04:38:34 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL8Ls-0006or-8p for emacs-devel@gnu.org; Thu, 28 Mar 2013 04:38:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UL8Lq-00041m-JB for emacs-devel@gnu.org; Thu, 28 Mar 2013 04:38:28 -0400 Original-Received: from vms173013pub.verizon.net ([206.46.173.13]:60417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL8Lq-00041Y-CO for emacs-devel@gnu.org; Thu, 28 Mar 2013 04:38:26 -0400 Original-Received: from TAKVER ([unknown] [72.66.125.164]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MKD00DKO3ZAJ810@vms173013.mailsrvcs.net> for emacs-devel@gnu.org; Thu, 28 Mar 2013 03:37:59 -0500 (CDT) In-reply-to: <87ehf0b3x2.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Thu, 28 Mar 2013 12:26:33 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.46.173.13 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:158343 Archived-At: "Stephen J. Turnbull" writes: > 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? yes, or a small group (~ 5 people), with a well controlled branching policy. > 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. That we do; each release is a branch, and new work happens both on trunk for major new features, and on the release branch for patches. Eventually they get merged together. > 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. Yes, that is typical. > 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! We often get criss-cross merges with short paths; people do work on the same branch in parallel. You are correct that sorting out the conflicts when the path to the ancestor is long is inherently hard. monotone/DVC presents the relevant files in a nice way, and allows the user to take their time in sorting things out. The conflict resolution state is saved on the disk, so you don't have to resolve all conflicts in one interactive session. > > 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. Hmm. According to https://www.kernel.org/pub/software/scm/git/docs/git-rerere.html, 'git rerere' is for conflicts that happen again on subsequent merges. monotone (in recent heads, not in the current release) has that for dropped/modified conflicts; I haven't felt the need for it for other types of conflicts, but it would be easy to add. --resolve-conflicts-file specifies the resolutions for one merge; it does not make sense to save the whole file for a subsequent merge. It might make sense to save parts of it. 'git rebase' is similar to 'mtn merge'; 'git rebase --continue' appears to support a "merge" that stops partway thru due to a conflict, which the user must then resolve before resuming the merge, and getting to the next conflict. So the user does not see all conflicts at once, which makes the conflict resolution harder. It is especially frustrating if you don't know how many conflicts there are; how much time will be needed to finish the merge. Is there a git command that lists all conflicts in a rebase before starting? When git rebase hits a conflict, it creates a local file with CVS-style conflict markers. monotone just notes the two file versions, and the DVC front end pops up an Emacs ediff; that's better than Emacs' CVS conflict mode. git then requires 'git add' commit to indicate the conflict resolution. This leaves the workspace in an odd state; is there a git command that indicates the workspace is in the middle of an interactive rebase? Suppose you are interrupted, and come back in a week; can you tell what state the rebase is in? In monotone, all of the conflict resolution is done outside the workspace (in /_MTN/resolutions/*), and it is always clear what is going on. These are not fundamentally different approaches (they do solve the same problem), but the details can matter when you do this a lot. I assume git could be enhanced to be more similar to monotone in this area; I'll probably be forced to do that when monotone finally dies :(. -- -- Stephe