Comments 136
Надмозг выражает свое удовольствие.
Обсуждать проблему грамматики английского в переводе на русский - это, право, по-гусарски слишком.
Удовольствие выражено надмозгом.
Использование токсично-манипулятивно-низковибрационного повелительного наклонения забьет последний гвоздь в попытках пронести стильно-модно-молодёжный Rust в ядро 🙂
Текст в коммите должен быть продолжением фразы "This commit will..." именно это даёт самые короткие и ёмкие тексты в английчком: fix #66, create alternative connections, update comments, make america great again, set up a double thread pool.
Будущее время вместо прошлого в отчёте о проделанной работе? Я пользуюсь формулой %problem% [is/are] %state%.
#66 fixed, alternative connections created, comments updated, america made great again, a double thread pool set up.
Это тот самый страдательный залог, с которым борется Линус, и я теперь не знаю, как жить дальше. Всё-таки Линус, не хрен с горы. Просто зачем везде писать “I”? I fixed…, I created…, I made…
Так Линус старой закалки программист- предкомпилятор же. Он когда коммит видит, по привычке хочет получить ответ на вопрос, а что будет, если он пропустит этот коммит в ядро. Но так как соревноваться с современными компиляторами трудно, просит прямо писать в описании ответ на свой вопрос.
Наверное, вопрос больше в том, как человек воспринимает сам комит. Я так понимаю, для тебя коммит - это нечто совершённое, поэтому тебе удобнее описывать его в прошедшем времени. Типа, человек склонирует репозиторий и в этом репозитории уже всё произошло.
Я же, например, воспринимаю коммит чуть иначе. Для меня он характеризует изменение, которое произойдёт с исходниками, если применить этот коммит. Поэтому мне проще и удобнее описывать его как "что он делает" или "что сделает".
Хм, если бы не этот пост, я бы и не задумался об этом никогда...
На гитхабе есть же гайд по соглашению в названиях коммитов и готовый линтер, который можно ставить на прекоммит эвент в vs code, например, и бить по рукам тех, кто забывает следовать гайду.
Я ещё не встречал линтеров, который мог бы различать страдательный залог и действительный.
Скоро LLM будут комментарии к коммитам генеритть.
Скоро LLM будут комментарии к коммитам генеритть.
Такая функция есть как минимум в VS, VSCode и AI Assistant от JetBrains . Иногда получается даже смешнее, чем у https://whatthecommit.com/ .
GitHub Copilot встроенный в Visual Studio уже умеет. Правда получается чересчур многословно, но пару фраз оттуда можно надёргать себе.
у вас грамматическая ошибка. дословно: #66 исправляла, альтернативные соединения создавали, коментарии обновляли... Для создания страдательного залога (#66 исправили) надо использовать конструкцию <подлежащее> <to be в нужной форме и с грамматическими дополнениями> <сказуемое в третьей форме>
Думаю как раз для избавления от такой дикой безграмотности Линус и просит перейти на более простую форму активного залога.
Обратите внимание на квадратные скобки.
%problem% [is/are] %state%
У заголовков (к которым относится заголовок коммита) своя грамматика. В них допустимо сокращать to be для страдательного залога, если он очевиден из контекста. Например: YouTube playback issue fixed. Другой пример — опускание is about или is going. Что-то типа: Linus Torvalds to Fight Passive Voice. На первый взгляд тоже может показаться, что грамматика сломана, но я часто вижу именно такие заголовки.
Немного не так. Когда есть герундий (глагол с ing-овым окончанием), это уже не может быть пассивным залогом. Формы модального глагола to be совместно с перфектной формой глагола могут образовывать страдательный залог, который очень удобен в безличных конструкциях. А именно безличные конструкции - стандарт в технической и научной речи. "An extraction was performed..., the condition was established..., the reaction product was obtained..., the genome was assembled."
В коммитах любят повелительное наклонение, потому что это самая минималистичная конструкция с чистой основой. Именно такого подхода придерживаются разработчики визуальных интерфейсов: "open the window", а не "by clicking you can open the window". Если говорить о коммитах, "Update README" и "this updates README" отличаются, второй вариант выглядит избыточным.
Я не понял, где вы видите герундий, и, честно говоря, какое это всё вообще имеет отношение к написанному мной. Я говорю, что:
“was” (и “is”) иногда допустимо опускать, когда предполагается сокращённая форма.
Сокращённая форма предполагается в заголовках газет и коммитов.
Любой, регулярно читающий газеты и коммиты на английском языке, должен автоматически вспомнить десятки примеров. Если этого не происходит, значит человек прочитал слишком мало заголовков или вообще не читал.
Бонусом приводились некоторые другие грамматические особенности заголовков, которые, опять же, легко заметить, читая новости.
Прошлое время в английском это на одну-две буквы больше. А главное, вы встречаете плеяду исключений. Появляется риск, что кто-то напишет "writed logs to DB" и потом будут проблемы это найти.
(английский - это три совершенно разных неродственных языка, грубо сляпаных вместе. Там одни исключения. ).
writed
wrote
Собственно, формула %problem% [is/are] %state% для того и нужна, чтобы вынести вперёд %problem%, как важную часть, а на fixed/added/created/made/whatever забивать, поскольку это чисто грамматический сахар (и из контекста понятно, что #66 может быть только fixed).
writed logs to DB эту формулу нарушает. Должно быть что-то типа DB logging added или Logging to DB added, чтобы потом искать DB log (будет найдено DB logs, DB logging), ну или Logs to DB (если так вообще говорят). Ошибка в глаголе на результаты поиска не повлияет, если глагол не искать.
Кроме того, визуально искать что-то в списке, где каждый пункт начинается с существительного, тоже проще.
А может быть жизнеспособным подход %action% %problem%?
В фокусе action-глагол в инфинитиве для краткости и точности его формы: add, fix, update, remove, comment, test.
А problem на втором месте потому что может иметь разнообразные формы, которые легче понять зная контекст (action). Например: fix 66, fix download, test download.
А может быть жизнеспособным подход %action% %problem%?
Не знаю. Тут просто делятся своими подходами, я поделился своим.
В фокусе action-глагол в инфинитиве
Идея моего подхода как раз в том, что в фокус надо поместить, говоря лингвистической терминологией, пациенс — объект, над которым производилось действие. Анимация пыли в луче проектора добавлена. Эффект распыления удаляемого сообщения реализован. Окно «О программе» свёрстано. Функция хеширования файловых объектов написана. Обычно меня интересуют сначала все коммиты про анимацию пыли в луче проектора, а уже потом — какие из них её добавляют, какие — покрывают тестами, какие — делают совместимой с клавиатурной навигацией, какие — делают совместимой со скрин-ридерами, какие — удаляют.
Обычно problem более информативно, чем action.
английский - это три совершенно разных неродственных языка, грубо сляпаных вместе. Там одни исключения.
Родственных. Неродственных — это тюркские языки: сам+персидский+арабский.
Страдательный залог это сплошная самоуверенность. "#66 fixed", вот прям точно поправлено, твердо и четко. Не спешите, впереди ещё CI и регресс.
То ли дело скромный present simple "fixes #66", просто исправляет, ну по крайней мере пытается, а как оно на самом деле скоро узнаем.
С этим я соглашусь.
Но дело в том, что это не мой пример. Чтобы не наступать на эти грабли, номера тикетов я пишу вообще без ничего (#66), тем более, что с CI они превращаются в ссылку для открытия тикета или группировки коммитов, а остальное скромно дополняю: DB logging added, DB logging improved, DB logging tested and some bugs fixed. Никто же не говорил, что DB logging added correctly.
P.S. У любителей строгости видел правило обязательно сочетать: DBL-66: DB logging added, DBL-66: DB logging improved, DBL-66: DB logging tested and some bugs fixed. Мне норм и так, и так.
#66 fixed
Это обычное прошедшее время. "#66 чинил" (кто такой 66 и что он чинил - науке не известно).
кто такой 66 и что он чинил - науке не известно
Брат сорок четвёртого жеж!
Будущее время вместо прошлого в отчёте о проделанной работе?
Но ведь коммит это не отчёт. По сути ведь это набор изменений. И сообщение это описание этих изменений, что они делают.
А проделанной работа будет когда этот коммит вольют в главную ветку.
Текст в коммите должен быть продолжением фразы "This commit will..."
Скорее "this commit will OR code in this commit will ...". Есть всё-таки небольшая разница между
"Make editor display warnings in red color"
и
"Display warnings in red cilor"
в комментариях к коммитам.
Меня по началу немного корёжило от второго варианта.
В самом деле, так легче понять, что было уже изменено в коммите, нежели памятки "надо исправить" или "исправь это", поскольку в противном случае можно подумать, что коммит вносит изменения, не исправляющие, а требующие что-то исправить. Вдруг, автор коммита захотел в описание коммита сразу и всунуть памятку по типу "исправляет Х, но добавляет проблему У, которую исправим в U или Z". Может и нет, но при отсутствии дисциплины всякое может случиться.
Более однозначно, бесспорно, не делать коммитов без соответствующего тикета (при этом достаточно в коммите указать только номер и название тикета, все подробности же описывать комментариями к тикету) - так и дисциплина соблюдена и данные вопросы в принципе исчезают.
В оригинале ни о каких памятках речь не идёт. Это варианты текста комментария к одному и тому же коммиту. Как у переводчика "was fixed" превратилось в "должен быть поправлен" - загадка.
не делать коммитов без соответствующего тикета (при этом достаточно в коммите указать только номер и название тикета, все подробности же описывать комментариями к тикету)
Ну уж нет. Тогда из просмотра git log невозможно будет понять вообще ничего, не заглядывая по стопицот раз в трекер.
И что делать девопсине, у которого нет доступа к тикетам в джире, а пайплайн упал? Не делают так, соглашение [feat | chore | fix | ...] <описание изменений в императиве>. Иногда ставят ограничение на длину описания, чтобы не растекались по древу.
Сейчас набегут оскорблённые и будут писать, почему этот белый мужик диктует как нам комментировать коммиты:)
не взрыв а хлопок - ранее: голубец это хотя бы еда © мылодрама-2
Повелительное наклонение вызывает замешательство в отдельных случаях. Одной даме по фамилии Коллонтай на вечеринке представили молодого человека. Она пожала ему руку и представилась - "Коллонтай". Его мозг переклинило и он интерпретировал ее фамилию как глагол в повелительном наклонении. Он растерялся и робко спросил "А как это делается?". На что она быстро ответила "Пора бы уже знать, не маленький".
угу, "Душа Монаха" играет новыми красками, если первое слово -- деепричастие.
Русская языка — она такая!
Свою судьбу фигня и тля,
Слегка от солнца батарея,
Сказала — «каравай меня!»,
Прикрыв глаза и гонорея.
Весь вечер он её вокзал,
От страсти аж оранжерея,
Сандал, портал и просто трал,
С её экстаза портупея.
Возня синхронно и идея,
Всю ночь они горизонтали,
И лишь под утро, ассамблея,
Забвенья автомагистрали...
Del
Тем временем как минимум уже в 2013 году в гайдах git по именованию коммитов была фраза
Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behaviour. Try to make sure your explanation can be understood without external resources
as if you are giving orders to the codebase
и эти люди запрещают нам ковыряться в носу называть ветку "master"
Более того, в европейских ВУЗах давным давно этот гайд используют по дефолту. Когда в команду приходит очередной боец после каких-нибудь скиллбоксов и начинает креативить в названиях коммитов, это ничего кроме изумления не вызывает.
Тем временем как минимум уже в 2013 году
В 2024 нужно заменить буквально пару слов, чтобы смысл уловили даже дети:
-as if you are giving orders to the codebase to change its behaviour.
+as if you are giving a prompt to Codepilot to change the codebase.
А мне вот эта отличная статья из 2014 вспомнилась. На хабре вроде был ее перевод.
Мой самый частый комментарий в коммитах: "Work on SOME_PROBLEM. Not finished. Not working."
Для этого git stash подходит лучше, по-идее.
А заменить на "Partially solve SOME_PROBLEM"? Чтобы по канону.
Как вы из "Work on... Not working." получили "Partially solve"?:)
Да какое «solve partially», когда оно обычно ничего не решает. Наоборот, если скомпилировать этот коммит, программа (или какая-то функция программы) работать не будет вообще, даже так как работала раньше.
Not finished. Not working.
ТУ много лет назад. Но я проверял "Not working" вместо "Doesn't working" приемлемо. Это сокращенная форма "Still not working".
Имхо «Try to fix it” вполне в ключе классического «fix it”. А потом фикс для предыдущего коммита, например :)
Doesn't working
Я очень надеюсь, что мой преподаватель английского этого не видит. Беспокоюсь за ее ментальное здоровье.
Проблема в том, что с точки зрения английской языки непонятно, кто not finished (подозреваю, что Вы), и что not working (подозреваю, что не Вы).
Аскинг! :-)
Git можно использовать по-разному. Коммиты в локальную ветку, как способ фиксации изменений. Эти ветки можно потом шарить с коллегами в виде PR/MR.
Но в ядре используются не ветки коммитов, а патчи. Патч это как правило законченный кусок работы.
Зачем так много слов? WIP, WIP2, WIP3, working solution.
Но это конечно с префиксом из номера таски, в которой написано кому, что и зачем нужно было поправить/сделать и в коментах описано "как".
Для этого принято использование аббревиатуры WIP (work in progress). Обычно с описанием проводимой работы через двоеточие ("WIP: description").
Minor fix (8 коммитов подряд, количество измененных строк очень разное),
более удобное для чтения, чем «Нулевой указатель должен быть поправлен»
..а где в исходном тексте что-то про "должен быть поправлен"?
Англичане генетически предпочитают passive voice, американцы - active. Это просто особенности воспитания и культурных традиций. Понятно, что когда они смешиваются в одном проекте, то выглядит странно. Как если два учителя общаются попеременке с ребёнком: один на "вы", а другой на "ты".
С другой стороны, linux во всем мире воспринимается как глобальный проект. Поэтому, почему бы не дать возможность людям демонстрировать свою культуру? В общем, посмотрим, чем все это закончится.
почему бы не дать возможность людям демонстрировать свою культуру?
Потому что цель проекта в другом.
Правило именования коммитов было прописано в гайде более 10 лет назад. Видимо у Линуса было хорошее настроение, чтобы еще раз его повторить.
«Юзеры общаются с компьютером на „вы“, программисты — на „ты“, а хакеры — на „ты, козёл!“» ©
После того, как Торвальдс переехал в США, его и понесло...
Белорусские лингвисты давно пытаются бороться с пассивным залогом. Тем более в язык почти отсутствуют церковнославянские причастия, которые его помогают выражать. В основном в виде ка́лек с русского языка.
Небритые белорусские лингвисты в ватниках пускают под отсос составы с пассивным залогом?
А если серьезно, то очень грустно, если лингвисты, вместо изучения языка, с ним борются. Впрочем, типичная история для Белоруссии.
Так в русском тоже дают рекомендации против чрезмерного применения страдательного залога, чтобы тексты были понятнее. Сравните: "лекция прослушалась студентами" и "студенты прослушали лекцию"; "Мяч бросался нападающим по воротам" и "Нападающий бросал мяч по воротам". Во втором случае чётко: субъект, действие, объект.
"Страдательный залог в коммитах был борим Линусом Торвальдсом" (церковнославянщина какая-то :)
В наших языках существует довольно продвинутая система окончаний. Благодаря этому в словах появляется избыточность и их можно переставлять в предложении с места на место как угодно. "Студенты слушали лекцию", "лекцию слушали студенты", "слушали студенты лекцию" и т.п. Конечно, порядок слов меняет эмоциональный окрас, но смысл по-прежнему считывается без ошибок. Страдательный залог, в нашем восприятии, выглядит избыточным и отдает канцеляритом. Хотя в некоторых случаях может быть вполне уместен. "Лекция окончена").
В английском есть лишь убогие s для множественного числа. Вместо окончаний, связь между словами в предложении определяется их порядком. Passive voice по сути является языком внутри языка, - надстройкой, которая позволяет в речи абстрагироваться от субъекта. Обойтись без этих наворотов конечно можно, но будет некомфортно.
В общем проводить параллели между английским и нашими языками здесь не вполне уместно. Они довольно разные, как C# и С++. Чтобы говорить на английском нужно в первую очередь научиться думать как они.
Факт в том, что в русском языке увлечение страдательным залогом портит текст, делает его неудобочитаемым и сложным для понимания. Это цитата от литературного редактора, текст по ссылке. А в технических текстах, коими являются и комменты на GitHub'e, как раз и хотелось бы максимальной ясности и краткости.
Вместо окончаний, связь между словами в предложении определяется их порядком
Вот именно! Русские окончания как раз и позволяют понять, что же Вы хотели сказать, даже несмотря на вкоряченную Вами совершенно излишнюю запятую.
в русском тоже дают рекомендации
Кто дает? Мне вот никто таких рекомендаций не давал. Может есть полтора фрика, которым пассивный залог жить мешает, но их возня, к счастью, пока не носит характер борьбы.
Буквально только что слушал одного толкового лингвиста (ищется как "Комолов Исаев Диалог"), так вот он утверждает, что лингвисты не меняют язык, и, тем более, не борятся с ним, а только изучают...
Ну да, возможно не то слово употребил. Лингвисты могут указывать на ошибки и давать рекомендации, как делать тексты понятнее и приятнее в чтении. Типа ерроров, ворнингов и хинтов в вашей любимой IDE. Вот эти "полтора фрика", как выразился комментатор выше, создали целый отдельный раздел языкознания - культура речи, по которому даже лекции читают.
Страдательный залог должен быть избегаем
Какое-то неправильное у него повелительное.
«Сим повелеваю: Исправить нулевой указатель! В противном случае - быть битому.
подпись: Цар унд Гроссе Кнейзе»
Вот это повелительное.
Страдательный залог размывает ответственность.
В английском важен порядок слов (SVO subject-verb-object), он определяет смысл сказанного. В отличие от русского здесь нельзя переставлять слова в предложении как угодно, иначе сказанное принимает совершенно иное значение.
Passive voice это стандартный способ в британском английском говорить о предмете, избегая упоминания субъекта. Кроме чисто утилитарного назначения - акцентировать внимание на сути, - они воспринимают такую речь как более объективную и вежливую. Описание изменений в коммите хорошо ложится в данную логику, поэтому вполне понятно почему многие пишут в таком стиле.
Манеру янки использовать здесь различные формы active voice тоже можно понять. Они по жизни стремятся к лаконичности и упрощению, особенно в письменной речи. А так фразы получаются короче и энергичнее, как в воинском приказе. Но для британского уха это звучит как кринж.
Однажды один лингвист залез в программирование - получился верблюд...
Теперь другой программист лезет в лингвистику...
Линус Торвальдс попросил разработчиков не использовать в коммитах страдательный залог, поскольку в языке есть более благозвучный действительный.
Так переврать источник надо ещё постараться. Основная мысль Торвальса: «Ребят, я из ваших описаний пулл-реквестов собираю сводный текст мерж-коммитов, а из-за того, что вы пишете их вразнобой, я не могу просто копировать предложения, мне приходится их переписывать в другую грамматику, это тратит время!».
I try to make my merge commit messages be somewhat "cohesive", and so I often edit the pull request language to match a more standard layout and language. It's not a big deal, and often it's literally just about whitespace so that we don't have fifteen different indentation models and bullet syntaxes. I generally do it as I read through the text anyway, so it's not like it makes extra work for me.
But what does make extra work is when some maintainers use passive voice, and then I try to actively rewrite the explanation (or, admittedly, sometimes I just decide I don't care quite enough about trying to make the messages sound the same).
So I would ask maintainers to please use active voice, and preferably just imperative.
Журналисты-насильники снова в деле
Я почему-то до сих пор не видел такого объяснения, особо не вникал и использовал страдательный залог, потому что действительный и впрямь выглядит как кривой американизм, а все эти версии про якобы приказания кодовой базе - натягивание совы на здоровенный глобус.
А оно, оказывается, вон как всё просто.
Напомнило два подхода к тексту объявления. Одни пишут "продаю квартиру", другие - "продам квартиру". Каждый раз, когда читаю второй вариант, сам себе в шутку говорю "хм, не продашь!"
Но можно первый вариант еще ухудшить - на двери кафе: "Требуется уборщица". Кто от кого требует? Наверное посетителями от кафе требуется чистота. Тогда почему объявление обращено к каждому посетителю?
"А мсье — оптимист!" лучше звучит ;)
Объявление на столбе "Лечу от всех болезней!". Мужик читает, усмехается: "От всех не улетишь".
Батя шарит в Си.
Думала, новость чисто на три плюсика будет, а тут портал в ад открылся
«Исправь нулевой указатель» — Это кривой перевод на русский. Правильно будет — «Исправить нулевой указатель».
Неопределенная форма глагола в русском это тоже повелительное наклонение, и именно такой вариант всегда используется в локализациях программ на русский язык. Например пункт меню Save будет звучать как Сохранить, а не Сохрани.
Поэтому Линус совершенно прав, но русскоязычные пользователи не всегда правильно понимают смысл этого требования к сообщениям коммитов.
На самом деле непонятно другое: такое требование - исключительно для удобства тех, кто принимает коммиты. Но в 99% случаев сообщения читают не эти люди, а другие разработчики, и в совершенно другом контексте. Поэтому если речь не о проекте типа линукса, где буквально один человек работает с коммитами сотен или даже тысяч других разработчиков, это очень странный карго-культ, как по мне.
Это бич сегодняшнего дня во всех сферах и областях жизни. Люди с кривыми мозгами, косноязычные, с трудом выражающие свои мысли, абсолютно не владеющие профессиональными терминами.
Мы все проблемы уже решили. Осталось только решить:
Как именовать переменные
Как инвалидировать кэш
Какой код на python более pythonic
Как обзывать коммиты
"Исправление нулевого указателя"
Вот и всё. Без вяских будущих и прошедших времён, без личных местоимений и прочих реверансов.
[Удалено]
Линус Торвальдс борется со страдательным залогом в коммитах