Часть комментария с датой - имеет право на жизнь (как писал Андрей в самом начало). Но остальная часть о том, что делает КОД, - лишнее

Если в комментарии не хочется употребить fuck hug - то он не нужен - и так все понятно будет.

В 2012 имеет. В 2021 - ни малейшего

Конкретно этот комментарий мной воспринимается, как запись о внесенных изменений и для чего она была сделана.
Если бы мы говорили о комментариях, которые делаются для упрощения понимания кода, тогда безусловно то что написано является излишним.

Ну и как по Вашему, для чего она была сделана?

Для гарантий кластер нужно перезапускать, либо перед обновлением, либо прям в скрипте при обнаружении неумираемого соединения.
Зависшие соединения от фз на кластере довольно старая боль кластера без путей обхода.

Чтобы через 10 лет вспомнили о нем.

/q

@otymko чтоб в стикер пак группы добавить реплайни на стикер /qs

Благодарю

Это если в пяти других местах нет такого же комментария, а код внутри не цитируется. Например там, где создаётся этот флаг, выносится на форму и тп. У нас в авторском комментарии идет фио, дата, номер/заголовок задачи. А комменты к коду если нужны - отдельными строчками. Может здесь так же

Команду необходимо писать в ответ на сообщение.

Кстати, гитблейм вместо авотрских комментариев не всегда спасает. Обновления от вендора размывают авторство.

коммитить вендора от имени вендора

Это делаем, но в этом и беда. Вот вася написал что-то в модуле. Коммит, код на васе. 1С перепахала модуль. Обновляющий коммитит естественно консистентное состояние новой версии. Только Васины строчки уехали в другое место. И теперь весь коммит записан на 1С. И блейм говорит, что этот код от 1С, а он - местами от васи.

надо разрабатывать в едт, там с поддержкой гита получше, чем в конфигураторе

В любом случае, код с исправлением конфликтов будет записан на исправляющего конфликты. Без "авторского" комментария теряется связь не только с автором, но и с задачей. Блейм будет ссылаться на мердж коммит обновления, а не на фичемердж.

А если переносить в виде патча тогда можно сохранить оригинального автора? Если сами по себе изменения при обновлении не требуют доработки.

различные правила доработки модулей на поддержке могут спасти в этой ситуации. В таком модуле врезка должна быть минимальна и там должен быть сопровождающий комментарий - зачем это сделано (не и не когда, а зачем). И даже если блейм покажет на этой строчке того, кто обновлял поставку, всегда можно провалится еще глубже и увидеть коммит. В 90% случаев в таких ситуациях комментария достаточно чтобы понять что тут происходит, а значит не надо искать ни автора ни дату внесения изменения.