Re: Need review of emacs-25-merge branch

[Eli Zaretskii]

> From: John Wiegley <address@hidden>
> Cc: address@hidden
> 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.