Re: Need review of emacs-25-merge branch

[John Wiegley <jwiegley@gmail.com>]

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

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

It's already up, in origin/emacs-25-merge. Perhaps you'd like to run some
tests on your machine locally, and then can you merge that branch into
'master' when you also feel it's ready?

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

Ah, yes, that was my question. I suspect the only "damage" possible is changes
now on master, as a result of the merge, that shouldn't be there, since they
should have remained on emacs-25 exclusively.

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

When emacs-25 merges into master, it is a merge of all the work done since the
last merge, minus those commits that should be skipped. This then defines a
new baseline against which the future merge occurs. This is the same workflow
that both merging and git-imerge are designed for. So I think we are on the
same page.

> IME, if we merge, say, once a week or two, there are almost no conflicts at
> all.

Either way, git-imerge should be equivalent in the end result to git-merge,
once I change it to take skips into account. So I guess it doesn't matter
semantically whether it is used or not; it helps me, personally, to reduce the
conflict surface I have to consider, by automating as much of the process as
possible. It may end up being something that only I use.

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

No, it would be optional. Since they should be equivalent in the end result,
there is no requirement to use it.

>> 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, I think Lars is looking into that now.

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