Story Time

As a package maintainer,

I want that changelog generation deals sensibly with merge commits,

because merging is sometimes necessary.

Acceptance Criteria

• A "fake" merge(*) is resolved by following the branch of the parent commit with the same tree id, ignoring the histories of the other branch(es).
• A "real" merge isn't resolved but flagged as an error. This is documented.

Background

Real merges of 2+ different branches are hard to transform into a linear changelog. While the commits on either side could be interleaved with each other (by commit timestamp), the EVR of each commit/entry wouldn't reflect reality, i.e. a commit that got one release number when it was built would get another when generating the changelog entry for it after the merge, i.e. the version-release part of the changelog header would be misleading. Instead of cracking the nut of "what is the right thing to resolve this", we should just fail in this instance, leaving it to the packager to resolve manually e.g. by generating the changelogs for all involved branches, merging manually and adding the result to the changelog file.

"Fake" merges(*) are done by specifying the ours merge strategy (git merge -s ours ...) which creates a commit having all merged branches as parents, but the resulting tree is that of the current branch. I.e. this is only a merge for "book-keeping".