Re: Need review of emacs-25-merge branch

[John Wiegley <jwiegley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4237 bytes --]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> 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. Several were in ERC, some in the NEWS file, some in eww, some in
autoloads, and a few in configuration file (.gitignore, etc).

If that's really what is needed, I can do that; however, then I'd need to redo
it to incorporate the correct changes. On the other hand, I could make the
change I propose below before re-attempting it, and maybe that will resolve
some of the problems I had.

>> 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:

  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?

  a. Whenever a merge is to be attempted between two points X' and Y' in the
     graph (the Python function in git-imerge that does this is called
     "automerge"), we check the commit message for a back-port marker, and a
     skip list. If we find it, we pass the strategy option to indicate an
     "ours" merge, which always succeed by definition.

Not only will this conform git-imerge to our process, but it accelerates the
merge process by reducing the number of potential conflicting merges.

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). After all, the
end result of either approach should, in theory, be the same. The main
advantages of git-imerge are:

  1. It automates finding the smallest possible conflict surface (trading
     compute time for human time).

  2. It guarantees you won't ever fix the same conflict twice, without using
     rerere (which can sometimes be too automatic, since it's pattern-based).

  3. It allows intermediate merge states to be communicated and resumed by
     another, and also built and tested, if desired.

  4. It allows the final merge state to be simplified in various ways, making
     it also useful for feature branch development where rebasing is used.

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?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]