When following Debian changelogs (e.g. via apt-listchanges or update-manager) one often wonders what an actual commit messages actually means or how a bug got actually fixed. Currently finding this information is cumbersome:
- Find out the version control system of the package, either via the PTS or via debian/control.
- Browse it's VCSs revision history either by using the web interface or by cloning the repository.
- Try to locate the correct commit from it's commit message. Hopefully it's the same as in the changelog and hopefully it mentions the bug number - otherwise: tough luck!
However this process can be automated if a package uses the following format for changelog entries:
* [commitd] changelog message
e.g.:
* [fed3f3d] fixed segfault during daemon startup (Closes: #7005180)
then you can use Cl2vcs to locate the exact commit that corressponds to that changelog entry. Cl2vcs uses the PTS to parse the packages Vcs-Browser URL to create a link back to the commit.
If you maintian your package in Git, creating this type of changelog entry is simple: You can tell git-dch to include N digits of the commit's SHA1 (the commit id) using the --id-length option, e.g.:
git-dch --release --auto --id-length=7
This way git-dch will include the first 7 digits of the commit's SHA1 (this options can of course also be specified in gbp.conf). Packages already using this are e.g. libvirt and calendarserver.
Note: a possibly useful extension of the above format would be:
* [commitid1,commitid2,commitid3] changelog message
so several commits can make up a changelog entry. For Subversion this would then look like:
* [r123,r125.r127] cleanup whitespace errors
