Need review of emacs-25-merge branch

[John Wiegley]

Bear with me, this is my first merge attempt, after a long period of no
merging having happened...

To make things easier on myself, I used git-imerge, which is a power tool for
managing large scale forks:

  
http://softwareswirl.blogspot.com/2013/05/git-imerge-practical-introduction.html

My experiences using it for this merge were:

  1. It's slow. It took 1.5 hours to do the merge.

  2. It's FAST. 98% of that time was spent watching it do automated bisecting,
     so I was able to read Emacs bug mail for most of that time.

  3. I was presented with a total of, I think, 16 conflicts. Except for one,
     each of these conflicts was a single, small conflict region within a
     single file.

     The problem is, each one was a genuine conflict, and I wasn't sure how to
     intelligently merge the two pieces of work. I did my best, but I'm sure I
     got it wrong in several places.

  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.

In all, this was an awesome experience -- if it actually worked. The amount of
intellectual effort was tiny compared to the scope of the merge, and noting
Stefan's experience. If this works, it's a huge win in the git-imerge column;
if it did a hatchet job, maybe not.

The resulting merge fails to build for me for the same reason that emacs-25
does: the ucs-normalize.el build failure.

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

signature.asc
Description: PGP signature