merging entries not from the head of the ChangeLog

[Glenn Morris]

Hi,

I've been using this plugin to merge some Emacs branches. It's been quite helpful. One issue that has come up:

People often like to edit older ChangeLog entries, eg to fix typos or fiddle with the line-breaks (sigh).
Often, they do this in the same commit as making a new ChangeLog entry.

If I use this plugin, it seems to cause ALL ChangeLog changes to get merged to the top of the destination.
Ideally, what would happen is:
Was the change in the source ChangeLog made at the head of the file?
 (Or, was it an addition, as opposed to modification of an existing entry?)
If yes, merge the change to the head of the destination file.
If no, merge the change as normal.

An example is attached:

source.diff = change that was made to a ChangeLog file in the source branch. There is one new entry at the top, followed
by two cases of just changing the line-breaks.

plugin.diff = result of merging with the plugin. All entries get merged to the top (so two will be slightly altered duplicates
of existing entries).

no-plugin.diff = result of merging without the plugin

ideal.diff = what would ideally happen

Is there any chance of making it work this way?

Thanks.

[Eli Zaretskii (eliz)]

Alternatively, perhaps bzr-changelog-merge could compare the two versions fuzzily, treating as different only those lines that are very different. I believe that's what git-merge-changelog does.

[Andrew Bennetts (spiv)]

Thanks for the report, and especially the examples. I'll give it a go.

[Andrew Bennetts (spiv)]

I should have realised from writing news_merge that this sort of thing involves an alarming number of edge cases, making it much trickier than it looks!

Anyway, the linked branch <lp:~spiv/bzr-changelog-merge/non-head-edits-723968> has some fancy logic that hopefully does what you want in this case without making it worse for the cases it already well on. That's the theory, some real world testing would be greatly appreciated (I have started an automated test suite in this branch, but it's pretty basic atm).

In short:

 * it should handle the case in this bug report: merging a branch that adds a new entry to the top as well as edits an old one
 * it tries to handle that even if the edited one is near the new one at the top (that bit is particularly messy!)
 * the original case I had in mind, both branches have simply added different new entries to the top since diverging should still work smoothly
 * if it gives bad results, run again with -Dchangelog_merge and attach the ~/.bzr.log output here.

[Eli Zaretskii (eliz)]

Thanks!

I installed the branch (by simply replacing the old changelog_merge.py in the plugins/ directory with the new one, is that the right procedure in this case?). So far, it passed its first baptism by fire ("bzr up" from the Emacs mainline) with flying colors.

Will keep you posted.

One comment: you removed from changelog_merge.py the documentation of how it works -- was that because it is redundant to a similar doc in __init__.py, or because it no longer describes accurately the effects of the merge in those simple situations? If the latter, then perhaps __init__.py should also be updated, because for now "bzr help changelog_merge" still says the same as it did before.

In any case, it would be good to update the help text to describe what the plugin does in its current incarnation.

[Eli Zaretskii (eliz)]

A merge to a feature branch, which included both entries added at the top of ChangeLog files and small modifications in past entries, also went fine.

Thanks!

[Andrew Bennetts (spiv)]

Thanks so much for the real world testing! In general replacing the whole changelog_merge directory in plugins is the way to try the new plugin (or use an environment variable such as BZR_PLUGINS_AT as a temporary override), but in this case I'd only updated the one file so that was fine.

I removed that description from the implementation because it's no longer accurate. It gives the right idea, but in practice that example doesn't actually work like that (the implied common BASE version in that example contains just OLD-1, so “OLD-2” would actually be new-in-this from the perspective of this algorithm). I noticed this when I tried to turn that exact example into a unit test :)

I've just updated the help text in __init__.py in a new revision to be accurate, although sadly a bit less concrete. You can see the change <http://bazaar.launchpad.net/~spiv/bzr-changelog-merge/non-head-edits-723968/revision/7>. You're welcome to suggest improvements, of course :)

Given that this seems to be working well I'll go ahead and merge this to trunk and close this bug… then propose bundling this plugin with bzr. Thanks!

[Eli Zaretskii (eliz)]

The new help text looks fine to me.

Having this bundled with bzr would be great.

Thanks!

[Glenn Morris (rgm+lp)]

Just wanted to say thanks for this. I've used it briefly, and it worked fine.
I haven't had chance to thoroughly test it out yet. I see it will be in future Bazaar versions
by default. Thanks!