Hi, On Tue, Oct 22, 2019 at 04:47:53AM +0200, Bastian Blank wrote:
> In Debian most people prefer to have changelog entries with all changes, > so changes always contain a modification to debian/changelog. It's worse than that: changelogs are supposed to contain the linear history of the branch they are on, so the bug tracking system can determine fork points and find out whether a particular bug is fixed in a particular version. > If we also start to use merge requests on Salsa, all those changes will > contain modifications to debian/changelog, which will usualy conflict > with each other. Or worse, are applied to an old changelog entry. This > for example happens on the linux packaging project. Yes, changelog merging needs to be special-cased with a tool that understands the semantics, in the same way you are not presented with a conflict resolution screen for the commit message when merging two branches in a VCS. Your proposal loses a bit of metadata in the VCS, because the changelog entry is shown as having been created by the final release commit, and backtracking through the VCS is made harder because of this. I'd consider "git blame debian/changelog" to be a very useful tool. Simon
