#285 some merge commits cause UNRESOLVABLE MERGE changelog entry even with [skip changelog]
Closed: Invalid 9 months ago by nphilipp. Opened a year ago by rathann.

I'm trying to update make an update to tin. A co-maintainer switched the package to rpmautospec a couple of releases ago. I'm planning to make the update to all stable branches as it brings a very welcome enhancement, namely NNTPS support. So, I'm doing my usual commit to oldest supported branch and merge upwards dance. However, rpmautospec makes a mess here. Doing git merge f36 in f37 branch and adding [skip changelog] kind of works, but it still bumps the release unnecessarily. It's annoying but I understand it's by design. However, doing git merge f37 on rawhide branch, even with [skip changelog], still produces - RPMAUTOSPEC: unresolvable merge changelog entry.


Hey, sorry for the late reply.

Releases are bumped on merge commits to keep things simple and deterministic. You could also make a build from the merge commit, so they must.

I’m unsure what you’re asking for… Should just the merge commit not produce a changelog entry (instead of the warning)? Because it still would have to cut off changelog generation there. Rpmautospec can’t programmatically guess what the “right” combined changelog of two disparate branches should be, which pieces from which side actually ended up in the tree after merging. There's one exception to that: If one parent commit has the same tree (as in: git object, say the result of git merge -s ours) as the merge commit, then it can ignore the other branchs (there's a valid changelog leading up to this “content” already which it can use).

Metadata Update from @nphilipp:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

9 months ago

Login to comment on this ticket.

Metadata