The list of changes for a build has several common scenarios where it is not correct.

1. When using one build job to handle multiple Git branches every time the job has to switch between branches, the list of changes "explodes" to show all differences between the branches.
2. When using build strategy that requires a fresh checkout/clone the list of changes are not reported at all
3. When you commit and build fails for "reasons", such as disk full or some service is down, when you re-run the job the new job does not show any changes

I believe this could be improved by doing something like the following:

• Store a "ref" and "revision" pair for last successful build. It should probably be configurable whether unstable builds are stored. "ref" would be something appropriate for the VCS such as a path in SVN or a ref in Git.
• If there is no stored ref/rev pair, then show the HEAD change in the list
• If there is a stored pair, then show all of the changes since that rev
• Of course update the stored pair at end of build if it is successful

A system like this could solve all of the problems mentioned and provide a more accurate picture of the relevant changes that contributed to the build.