I see the convenience of this, but it's more a matter of developer discipline than anything, isn't it?  I don't think you can actually remove the need for review of the tickets affected by a commit.  Suppose you make a change that affects two tickets, then back it out and commit a change that affects only one of them?  At that point, you'd have a ticket with an "affected by commit" comment and a second "affected by commit" comment, with no effective change in the code.  You surely would <em>not</em> want to back out any other changes to the baseline, so it wouldn't by very safe to back out ticket wiki changes&#8212;you could be "backing out" to a new leaf, instead of the baseline you had at the first commit.

It would be far better to document the "badness" of the original change in the code than to hide it in a commit comment (which may not even mention it) I would think.  This sort of thing may happen more than one would guess, especially if the code is under heavy development.

If this feature were implemented, it would have to be a toggle.  It would be better to make this a Th1 "plugin" and share it around.