From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Need review of emacs-25-merge branch Date: Wed, 30 Dec 2015 21:26:20 +0200 Message-ID: <83vb7fbuw3.fsf@gnu.org> References: <83fuyjdi2z.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1451503559 11165 80.91.229.3 (30 Dec 2015 19:25:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Dec 2015 19:25:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 30 20:25:51 2015 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 1aEMNa-0002ws-NY for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2015 20:25:50 +0100 Original-Received: from localhost ([::1]:53509 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEMNZ-0007vX-VZ for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2015 14:25:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEMNN-0007vM-BL for emacs-devel@gnu.org; Wed, 30 Dec 2015 14:25:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEMNI-00058c-Bs for emacs-devel@gnu.org; Wed, 30 Dec 2015 14:25:37 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEMNI-00058R-8M; Wed, 30 Dec 2015 14:25:32 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1820 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aEMNG-0006VU-8e; Wed, 30 Dec 2015 14:25:31 -0500 In-reply-to: (message from John Wiegley on Wed, 30 Dec 2015 11:07:30 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:197193 Archived-At: > From: John Wiegley > Cc: emacs-devel@gnu.org > Date: Wed, 30 Dec 2015 11:07:30 -0800 > > > It's hard to look at the humongous diffs without some focus. It would be > > better if you told where did the conflicts occur, so that only those parts > > could be eyeballed. > > I would have to redo the merge again to know exactly what those conflicts > were. (I miss Bazaar's ~/.bzr.log file where everything was logged, and could be readily produced for inspection many moons after stuff happened.) If recovering the conflicts is that much effort, then I guess there's no point in reviewing the merge any longer. Just push it, and let's see who hollers. > >> 4. It didn't take "back-port" markers into account, and yet it didn't run > >> into conflicts because of them either. I'd like to know if this mattered, > >> how you checked that it mattered, and based on that feedback I'll make > >> changes to git-imerge to choose the "ours" strategy automatically for such > >> commit pairs. > > > How does one go about this? > > git-imerge is a Python script. It does the following: Sorry, it seems I didn't make myself clear again. I was asking about this part: I'd like to know if this mattered IOW, I thought you were asking to see if the fact that the backports were not taken into account actually did some damage, and I was asking what should one look for to find any such damage. > 1. The number of new commits on master is X. > The number of new commits on emacs-25 is Y. > > This means there is a matrix of X*Y possible "merge points". > > 2. git-imerge searches the space of these merge points by bisection, to find > the bottom-right-most point in the matrix that merges automatically. This > then defines a "space below" and a "space to the right" within which the > merge might not proceed automatically. > > Note that this is equivalent to having done the clean merge at that point > earlier, and then moving forward through time from that moment. > > 3. It presents this bottom-right-most conflict in the form of a conflicted > merge between X' and Y', where X' < X and Y' < Y. > > 4. After you resolve this conflict, you resume the matrix-based merge. Now > you have two areas in which to repeat the same process: (X - X') * Y, and > X * (Y - Y') [each starting from X' and Y', respectively]. > > git-imerge attempts to "fill in" as much of these squares as possible via > automated merge, to reduce the candidate surface area. > > 5. Now the algorithm proceeds recursively in each sub-square, etc., until > the final squares are 1 commit tall and wide, such that they either pass > automatically, or require manual resolution. Then you are done. > > How do we change this algorithm to support gitmerge.el style merging? Frankly, I don't see how that would be needed, in the simple workflow we use around here. AFAIU, git-imerge was designed for much more complex workflows, with many branches that merge back and forth. We just have 2 branches whose fork point is well known, and which basically fork once and then never join. So, item 2 is known in advance, for example: it is currently the point where emacs-25 was created. (Once the merge is actually done, the next such point is where that merge happened.) And the commits to merge are all those made after the fork point on emacs-25, sans the "backports" and a few others that gitmerge.el knows about. That's all there is to it, I think. > Not only will this conform git-imerge to our process, but it accelerates the > merge process by reducing the number of potential conflicting merges. IME, if we merge, say, once a week or two, there are almost no conflicts at all. > In fact, now that I think about it, I can unite these two approaches by > changing gitmerge.el to use git-imerge instead of git-merge in > `gitmerge-apply' when available (and if customized to do so). Then you'd require everyone who uses gitmerge.el to have a working Python installation, and one that is compatible with Git. That's not a trivial requirement; e.g., Git for Windows is shipped without Python support. > So, I guess the question now is: Do you want me to make these changes to the > script and redo the merge, or should we just fix this mega-merge by hand? The latter, of course. If there's any trouble, we will know shortly. However, please do fix the problems I reported about, in the test/ directory, as I think it should be easy. Thanks.