On Mon, 20 May 2024 at 19:10:00 -0700, Otto Kekäläinen wrote: > Exact quote: "These commits have intentionally no debian/changelog > updates as it causes every single rebase or cherry-pick of a commit to > always have a merge conflict. It is much better to have all commits > as-is, and then right before upload just run gbp-dch --auto to > automatically generate the changelog."
This is not unique to Debian packaging: upstream projects that maintain a GNU-style ChangeLog and/or NEWS file have the same problem, for the same reasons. In the projects where I'm an upstream maintainer, we've generally solved this by having the detailed ChangeLog either auto-generated from `git log` at release time or not existing at all, and writing a more user-facing summary of changes into the NEWS file periodically during development (generally pushed directly by a maintainer rather than going via a merge request, because adding text to NEWS hopefully can't cause regressions), and in particular ensuring NEWS is up-to-date as part of the release procedure (a maintainer/release manager responsibility). Using `gbp dch` to maintain debian/changelog is analogous to that technique - the version auto-generated from `git log` acts as a first draft, and if a contributor wants to adjust the wording used in debian/changelog to be less about fine-grained technical details and more user-facing, they can use `gbp dch` to summarize all changes up to now, make the desired adjustments, `git commit -m 'Update changelog'` and push. Next time the changelog needs to be updated, `gbp dch` will start from just after the most recent change that touched debian/changelog. smcv