Как мне кажется, многое зависит от того, кто именно будет пользоваться комментариями (разработчики программы, пользователи и т.п.) и как именно, отчего и будет зависеть уровень абстрактности комментария и его содержание.
Оптимальным, на мой взгляд, является написание комментария как краткого описания изменений с позиции собственного видения смысла вносимых изменений, руководствуясь при этом фактически произведёнными изменениями (т.е. не «улетать» слишком высоко в абстракции при описании изменений) и исходить из того, что комментарии предназначены для разработчиков. Если исправляется орфографическая ошибка, то в комментарии следует указать, что «исправлена орфографическая ошибка», если изменены несколько участков кода ради общей логики, то следует описать что именно за логика подразумевается (т.е. дать именно описание общей, абстрактной логики, а не перечислять изменённые методы, классы и т.п.).
В случае Вашего примера, думаю, следовало написать что-то вроде «Убран лишний вызов функции getCharset в CurlResult::fetch» (чтобы были ясны Ваши намерения; Вы же убрали вызов так как он лишний (о чём потом даже написали в своём посте — «просто лишний раз дергал метод»), а не ради исправления какой-то ошибки).
Что касается использования в комментарии названий сущностей из программного кода (имён методов, классов, пространств имён и т.п.), которые были изменены, то, на мой взгляд, следует пытаться находить баланс между желанием конкретизировать область изменений и размером комментария (т.е. я за присутствие в комментарии указания на область изменений, просто конкретизация будет варьироваться от названия конкретных сущностей из программного кода до обобщённых названий). Так, например, вместо комментария «добавлена поддержка рекурсивного удаления файлов» я бы предпочёл комментарий «добавлена поддержка рекурсивного удаления файлов в функции removeDirectory»), а вместо комментария «добавлена поддержка событий в классах Plugin1, Plugin2, Plugin3» предпочёл бы «добавлена поддержка событий в плагинах».
Ещё можно попробовать настроить программу просмотра таким образом, чтобы она в начале комментария выводила общий для всех изменённых файлов путь (поможет, если в программе соблюдается соответствие между именем файла и программной сущности, содержащейся в нём).
