I know that Subversion (what we're using at work) can be configured to require comments on commits, however I'm not in a position of power to simply turn this on.  I know that my reason for commenting my commits is because it is useful, if only as a memory-jogger, to quickly understand the reason behind the commit.  However, this doesn't seem to be enough to combat the two responses I always get:


It takes too long and I just want to get my changes into the repo.
It's easy enough to just look at the diffs.


I even show them the value of simply putting in a JIRA issue ID and how it automatically gets tied to the issue, but still no dice with them.

Worst of all, the person who can make the call is in the same camp: doesn't want to bother and is fine with looking at diffs.

I know it's the right thing to do, but how can I make them see the light?  Even if I can't convince my fellow devs, how can I convince management that it's the right thing to do for the business?

Focus on "Why". Its all very well looking at the diffs and seeing that someone changed the logical flow of a section of code or something like that, but why did they change it? The why is usually in the associated ticket (JIRA for you). 

They may wonder why the "Why" is important but in 2 years time when you have caught some bug that is a knock on effect of that change, knowing why it was done is incredibly important for not only fixing your new bug, but making sure you don't cause the old bug to re-emerge.

There is also the auditing reason. Binding commits and ticket id's make it really easy to say ok, we're pushing out Version 2, this fixes defect 23, 25, 26 and 27 but there are no commits against defect 24 so it is still outstanding.
