Re: Rewriting bzrmerge.el

[David Engster]

David Engster writes:
> Stefan Monnier writes:
>>> On second thought: Do you mean we should just merge them in a series of
>>> merge commits (maybe in a temporary branch as to not pollute 'master'
>>> too much)? That's easy, of course. I was hoping I could somehow
>>> replicate the workflow we did with Bazaar, where we had one single merge
>>> commit for each merge.
>>
>> It doesn't matter if it's a single commit or not.
>
> OK, I've done the rewrite but I need to clean it up a bit, which I'll do
> over the weekend.

First iteration is attached. See comment for a quick intro. Please tell
me if it's OK to commit or if larger changes are needed.

If anyone starts hacking on it, please try to keep it general, meaning:
do not hard-code branches or repositories. My plan is to extend this for
the CEDET merge (in fact, the whole major mode thing is mostly lifted
from my existing CEDET merge script).

There are bugs, obviously, so don't push too fast. Also, you'll see that
our regexp for detecting backports is pretty loose...

Also note that - as I've already written - skipped commits will create a
separate merge commit (it will combine consecutive skipped commits,
though). Squashing those merge commits can be done, but I've not yet
built that in.

-David

gitmerge.el
Description: application/emacs-lisp