I'm working on a project where we have the source control set up to automatically write notes in the bug tracker. We simply write the bug issue ID in the commit message and the commit message is added as a note to the bug tracker.
I can see only a few downsides for this practice. If sometime in the future the source code gets separated from the bug tracking software (or the reported bugs/issues are somehow lost). Or when someone is looking in the history of commits but doesn't have access to our bug tracker.
My question is if having a bug/issue reference in the commit message is considered good practice? Are there some other downsides?
We have adopted this practice and it works very well for us. The tight integration between version control system (VCS) and other systems we use, e.g. continuous integration, bug tracker, etc. is extremely valuable. If we ever change anything in the future we certainly will have to assess the side effects, including the links between the VCS and bug tracking system.
In general I would see this as good practice. For some tracking systems there are additional options and tools available, for example bugtraq properties for Subversion (SVN). This suggests that quite a few people see value in this practice.
If you want to make really, really sure that no information is lost even if you may use a different bug tracker in the future or your bug tracker data somehow disappears, why not just put both the issue ID and a short explanation about the bug into the commit message?
Fix bug #123: app crashed after login
Then you still have the link from the history of commits to the bug tracker - and if the bug tracker should ever be not available, you can still see in the history what this particular bug was about.
This is very common practice, and I have found it extremely convenient. I use TRAC, so I can read the code history and navigate to the task that drove the change, or read the task history and navigate to the code changes.
"If sometime in the future..." If you separate the code from the bug tracker, then the old revision history probably won't be of further interest.
I use this practice too and I consider it a very good one. But besides the issue ID, I add a short description of the bug / feature (usually the title from the bug tracking system). This often helps save time because I don't have to lookup in the bug tracking system (beacuse I recognise the change) AND, like you said, if somehow I lose the bug tracking system, I'm not completly lost.