Постоянно ловлю себя на том, что пишу комментарии к коммитам на весьма неряшливом английском языке.
Ну там артикли проглотить, инфинитив вместо прошедшего (а тем более, перфекта) и всё такое.

Вроде как и стыдно, а вроде как и мы тут не в литературном кафе, мизинчик не оттопыриваем и монокль не роняем.

За комментариями в коде слежка гораздо тщательнее, пиджин и кокни через ревью не пройдут.

Опять же, ограничения на длину комментария и количество всякого технического шлака (номера тикетов, автогенерённый текст мерж-коммитов и т.п.) демотивируют от изящной словесности.

Вопрос к уважаемой публике: а как у вас с этим делом?
Особенно, в компаниях с нейтивспикерами в коллективе. У них глаз не дёргается от кривых комментов в системе контроля версий? Или они сами способны pink up phone and say yellow?

Здравствуйте, Кодт, Вы писали:

К>За комментариями в коде слежка гораздо тщательнее, пиджин и кокни через ревью не пройдут.

У вас commit message в ревью не отображается? Чем пользуетесь?

Здравствуйте, Кодт, Вы писали:

К>Ну там артикли проглотить, инфинитив вместо прошедшего (а тем более, перфекта) и всё такое.

В известной документации наоборот говорят:

https://git-scm.com/book/gr/v2/Distributed-Git-Contributing-to-a-Project
It’s also a good idea to use the imperative present tense in these messages. In other words, use commands. Instead of “I added tests for” or “Adding tests for,” use “Add tests for.”

Хотя я чаще всего использую прошедшее.

К>Опять же, ограничения на длину комментария и количество всякого технического шлака (номера тикетов, автогенерённый текст мерж-коммитов и т.п.) демотивируют от изящной словесности.

Какое ограничение на длину? Ограничение длины первой строчки что ли? — так она же памятникрезюме, для краткого вывода, есть же ещё строчки за второй — в которые и нужно писать что, да почему.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

К>>Ну там артикли проглотить, инфинитив вместо прошедшего (а тем более, перфекта) и всё такое.

EP>В известной документации наоборот говорят:
EP>

EP>https://git-scm.com/book/gr/v2/Distributed-Git-Contributing-to-a-Project
EP>It’s also a good idea to use the imperative present tense in these messages. In other words, use commands. Instead of “I added tests for” or “Adding tests for,” use “Add tests for.”

EP>Хотя я чаще всего использую прошедшее.

Правильно — инфинитив/настоящее. Потому что в прошедшем надо писать, что было и что было "не так".
А если новое — в прошедшем, то предыдущее — в past perfect? От такого точно застрелиться можно.

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

EP>Какое ограничение на длину? Ограничение длины первой строчки что ли? — так она же памятникрезюме, для краткого вывода, есть же ещё строчки за второй — в которые и нужно писать что, да почему.

+100.

К>Вопрос к уважаемой публике: а как у вас с этим делом?
Главное номер тикета указать и статус (закрыл, для тестирования и т.п.), развернутые подробности в багтрекере.

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

К>Или они сами способны pink up phone and say yellow?
И сами способны , лень это общая черта хомо сапиенс, без относительно языковой принадлежности.

Здравствуйте, Hobbes, Вы писали:

К>>За комментариями в коде слежка гораздо тщательнее, пиджин и кокни через ревью не пройдут.

H>У вас commit message в ревью не отображается? Чем пользуетесь?

Всё отображается, это веб-интерфейс битбакета.

Просто если к качеству кода требования высокие, то к коммит-мессажам — постольку-поскольку.

Номер тикета нужен, чтобы в багтрекере триггер сработал на публикацию пул-реквеста, ну и чтобы потом можно было спустя годы найти концы.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Какое ограничение на длину? Ограничение длины первой строчки что ли? — так она же памятникрезюме, для краткого вывода, есть же ещё строчки за второй — в которые и нужно писать что, да почему.

Из командной строки многострочный текст мрачно набирать, — даже если это баш.
А гуишные утилиты как-то проигрывают по удобству, так уж исторически сложилось.

Здравствуйте, Кодт, Вы писали:

EP>>Какое ограничение на длину? Ограничение длины первой строчки что ли? — так она же памятникрезюме, для краткого вывода, есть же ещё строчки за второй — в которые и нужно писать что, да почему.

К>Из командной строки многострочный текст мрачно набирать, — даже если это баш.
К>А гуишные утилиты как-то проигрывают по удобству, так уж исторически сложилось.

По-моему, в обоих случаях запускается полноценный текстовый редактор... или ты только через -m задаёшь текст? А зачем?

Здравствуйте, Кодт, Вы писали:

К>>>За комментариями в коде слежка гораздо тщательнее, пиджин и кокни через ревью не пройдут.
H>>У вас commit message в ревью не отображается? Чем пользуетесь?
К>Всё отображается, это веб-интерфейс битбакета.
К>Просто если к качеству кода требования высокие, то к коммит-мессажам — постольку-поскольку.
Ну это от вашей команды зависит только. Если всем пофиг... то значит всем пофиг — и довольно сложно заставить всех уделять этому внимание. Хотя, по-моему, коммит-мессадж — часть кода, более важная, чем комментарии.

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

Сообщение коммита должно быть понятным, на нобелевку по литературе оно не претендует, поэтому артикли и запятые могут быть не там не теми или совсем не быть. Сообщение коммита должно быть составлено так, чтобы продолжать фразу "this commit will <тескт сообщения коммита>". Первая строка должна отобразится на GitHub, остальное переносится на 3-ю и далее строки (вторая пустая).

А вообще вот: https://chris.beams.io/posts/git-commit/

Здравствуйте, Кодт, Вы писали:

К>Особенно, в компаниях с нейтивспикерами в коллективе. У них глаз не дёргается от кривых комментов в системе контроля версий? Или они сами способны pink up phone and say yellow?

Поначалу переписывали коммитлоги целиком, исправляя язык по дороге, но это больше оттого, что они просто были неправильно написаны логически. Я поднатаскался — теперь исправляют только опечатки, но фразы и всякие артикли не трогают, ленивые.

После китайцев — мы огого еще как здороово пишем.

Здравствуйте, Кодт, Вы писали:

К>Из командной строки многострочный текст мрачно набирать, — даже если это баш.
К>А гуишные утилиты как-то проигрывают по удобству, так уж исторически сложилось.

git можно заставить запускать vim/emacs, но я для коммитов больше пользуюсь git citool.

Здравствуйте, Кодт, Вы писали:

EP>>Какое ограничение на длину? Ограничение длины первой строчки что ли? — так она же памятникрезюме, для краткого вывода, есть же ещё строчки за второй — в которые и нужно писать что, да почему.
К>Из командной строки многострочный текст мрачно набирать

Как уже выше сказали — git commit без -m вызывает настроенный по вкусу редактор.

К>, — даже если это баш.

Вот кстати в баше есть секретный хоткей "Ctrl+x Ctrl+e" который вызывает внешний редактор для текущей строки ввода (это на случай если всё-таки хочется через -m, или безотносительно Git'а ввести длинную команду).

К>А гуишные утилиты как-то проигрывают по удобству, так уж исторически сложилось.

Magit очень удобен (кстати автор недавно собрал четыре мегарубля для дальнейшего развития на кикстартере).

Здравствуйте, aik, Вы писали:

aik>git можно заставить запускать vim/emacs

Да и вообще любой внешний редактор.

Здравствуйте, Кодт, Вы писали:

К>Вопрос к уважаемой публике: а как у вас с этим делом?
К>Особенно, в компаниях с нейтивспикерами в коллективе. У них глаз не дёргается от кривых комментов в системе контроля версий? Или они сами способны pink up phone and say yellow?

За все время работы с натив спикером он меня поправил только один раз — в то розовое время,когда я писал crush вместо crash.

Здравствуйте, Кодт, Вы писали:

К>Вопрос к уважаемой публике: а как у вас с этим делом?
К>Особенно, в компаниях с нейтивспикерами в коллективе. У них глаз не дёргается от кривых комментов в системе контроля версий? Или они сами способны pink up phone and say yellow?

Глянул сейчас коммиты от нейтива, который всегда говорит и пишет грамотно.
Да, пишет грамотно и в Perforce. Но.
Разброс по временам присутствует ("updating"/"updated"/"update", а иногда и без глагола, "updates").
Точка в конце иногда есть, иногда нет, начало сообщения с большой или с маленькой буквы.

Что я стараюсь делать, так это после заголовка делать два перевода строки и описывать подробно, зачем я что делаю, и ещё оставлять упоминания людей, которые ревьюили это.
Потому что читать это будут при "blame"/"annotate", и, соответственно, делать это будут не для литературного удовольствия, а в поисках информации.