Package: dpkg-dev
Version: 1.22.11
Severity: minor
X-Debbugs-Cc: ni...@thykier.net
Hi,
The manpage of `dpkg-mergechangelogs` suggests `-m` in its git config
rune under "INTEGRATION WITH GIT". The `-m` option is documented as:
```
-m, --merge-prereleases
Drop the part after the last tilde in the version number when
doing version comparison to identify if two entries are
supposed to be the same or not.
This is useful when you keep using the same changelog
entry but you increase its version number regularly. For
instance, you might have 2.3-1~exp1, 2.3-1~exp2, ...
until the official release 2.3-1 and they are all the same
changelog entry that has evolved over time.
```
It has no mention of treating `~bpo` (backports versions) specially, so
it sounds like it would do the opposite of what you want when merging
for stable-backports. Here it would be an error for historical ~bpo
entries to be merged into another version.
To be honest, the example might not be helping me here. As I read it, if
I use -m, then 2.3.1~exp* will be merged into 2.3.1-1 by the tool. That
does not seem like a safe default if it applies to historical versions.
Though teddybearing while writing the bug made me think it only applies
to the parts of the file that changed (would have a merge conflict), so
maybe it is all fine (but then, how does it work on an ff-only merge?).
Nevertheless, I feel we owe the next point a note on "This works
correctly for Debian backports" or "if you primarily use this for
merging into backports branches, you do not want -m because it will
wreck your changelog".
Best regards,
Niels
