agx@sigxcpu.org

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: