It's not just the commit message, but the fact that it's a single commit with >100k lines changed (though, if that's just a merge commit, it might be not super unusual for that kind of workflow. Though big merge commits are a good place to hide things in git, given that they can introduce their own changes)
> It's not just the commit message, but the fact that it's a single commit with >100k lines changed
When you diff the `bash-5.3` tag against the `bash-5.3-rc2` tag, the set of changes is reduced by a ton. It's the same story with previous release commits (at least for as far as I care to go back)... there's a "next version" branch that gets tagged with alpha, beta, and rc releases, and then there's a release commit that's made on master with the changes from the "next version" branch, plus some additional changes.
Why do they do things this way? I have no idea, but it clearly seems to work for them.
Because historically, what's in a release tarball is not what's in the repository. In many cases, the release tarball of an old C/autoconf project has "half-built". Debian has always worked from the release tarballs, and thus if you "just" import Debian packaging into a VCS, you don't necessarily track every upstream commit, just the releases.
(Independently importing release tarballs into VCS also worked better in the era of a dozen competing VCSes, without reliable export-import pipelines.)
I think you're either confused, or have attached your comment to the wrong parent?
My observations and questions were about the GNU bash git repo and how (and why) the bash maintainers do release branching and tagging. They were not about how the Debian folks handle their packaging.
