NetBSD переходит на Mercurial. И Git. Одновременно.

Ну, то есть, если бы в Subversion починили ветки, он бы не сдох? Сомневаюсь.

Если в проекте есть блобы, то я бы разделил его на 2: блобы - в Subversion, код - в DVCS. А то я уже вроде рассказывал про случай, когда у заказчика контент сайта сохранялся в Git и один раз они случайно туда запушили пару видео по 1GB. После этого git status выполнялся по 30 секунд...

git describe по умолчанию учитывает только annotated теги и это пару раз ломало генерацию билдов, когда люди руками их делали вместо скрипта, которым надо было.

Я не вижу git describe в твоём списке.

JJ умудрился даже это сломать, например, и назвать commit change’м.

Возможно, но с другой стороны это точно так же сломает любой фронт к git, будь то magit, vscode или idea. Тут придётся выбрать один из двух стульев: или git прост и достаточно хорош, чтобы 99% разрабов им без проблем пользовались, или у git есть куча трудноуловимых нюансов, на которые надо всё время обращать внимание.

2 X-Pilot

Если в проекте есть блобы, то я бы разделил его на 2: блобы - в Subversion, код - в DVCS. А то я уже вроде рассказывал про случай, когда у заказчика контент сайта сохранялся в Git и один раз они случайно туда запушили пару видео по 1GB. После этого git status выполнялся по 30 секунд…

Поздравляю, ты изобрёл git-lfs :D

Я не вижу git describe в твоём списке.

Потому что его там нет.

Возможно, но с другой стороны это точно так же сломает любой фронт к git, будь то magit, vscode или idea.

С чего бы? Они оперируют тем же понятиями. В ui bitbucket те же термины, что и в git, например.

С чего бы? Они оперируют тем же понятиями. В ui bitbucket те же термины, что и в git, например.

В 100% случаев? Я не уверен. В том же git нет понятий pull/merge request, например.

В любом случае, я думаю, ты понял мою идею.

Там есть понятия fast-forward, no-ff и merge. Поэтому нет расхождений что произойдет и всем все сразу понятно. А вот что там JJ делает уже придется отдельно натягивать.

И что именно оно должно мне посчитать?

Очевидно размер of repository happiness.

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

Вручную делать hg rename|mv|whatever – это конечно никуда не годится.

Не знаю на кого расчет. Но отслеживать – это когда программа отслеживает. А не пользователь.

Я и git mv в гробу видел делать.

Архитектурно Mercurial лучше, чем Git.

Ещё скажите на вкус лучше. Не знаю что там за бред по ссылке, которая не грузится. Может перескажите кратко?

Если кратко: модель хранения Git подвержена проблеме, что на каждый коммит может создаваться по несколько объектов и на очень больших кодовых базах (60 MLoC+ как у Facebook), где много коммитов и много авторов, она не справляется.

Mercurial хранит данные в виде revlog'а: для каждого файла создается пара «индекс» и «данные». В данных может находиться как бинарная дельта, так и полный снэпшот файла. В индексе находится сдвиг по которому нужно читать внутри файла данных и таким образом получить его текущее состояние.

Насколько я помню, после выхода этой статьи в Git улучшали систему упаковки данных, но выглядело это костыльно. Ну и еще: очень забавно видеть, когда git запускает git gc, потому что, блин, в нем нет «веток» (в нем есть только «reference'ы», а это не одно и тоже) и дерево растет от «head» к корню (нулевому коммиту), а не от корня к текущему коммиту (как во всех других VCS).

Поздравляю, ты изобрёл git-lfs :D

Оно выглядит как костыль: добавляем метаданные к тому «что нужно считать как файл для lfs, а что нет»... :( Я бы, ни в git, ни в mercurial такое не использовал, а предпочел бы что-то более специализированное...

Edit: и да, не использовал, и потому, могу быть не прав
Edit2: если LFS требует указывать какие типы файлов должны храниться как блобы, то в моем примере оно бы вряд ли помогло: менеджеры вообще ничего не знали про git (для них это было «отредактировать сайт»->«сохранить», а под капотом там был git) и никто не ожидал, что они так сделают.

Если кратко: модель хранения Git подвержена проблеме, что на каждый коммит может создаваться по несколько объектов и на очень больших кодовых базах (60 MLoC+ как у Facebook), где много коммитов и много авторов, она не справляется.

У Facebook какой-то свой взгляд на VCS просто. Он не эталонный, и даже не средний, а статистический выброс. Пусть сами со своими проблемами и разбираются. Потому что способов неправильно использовать инструменты масса. Инструменты тут не при чём.

Mercurial хранит данные в виде revlog’а: для каждого файла создается пара «индекс» и «данные». В данных может находиться как бинарная дельта, так и полный снэпшот файла. В индексе находится сдвиг по которому нужно читать внутри файла данных и таким образом получить его текущее состояние.

Да, отстой полный.

Насколько я помню, после выхода этой статьи в Git улучшали систему упаковки данных, но выглядело это костыльно.

У Гита сделано круто. Не меняя основной концепции, что фиксация – это снимок всего репозитория. Безо всяких индексов и прочего. Без ненужного усложнения. Есть проблема сжатия. Она и решается.

Ну и еще: очень забавно видеть, когда git запускает git gc, потому что, блин, в нем нет «веток» (в нем есть только «reference’ы», а это не одно и тоже) и дерево растет от «head» к корню (нулевому коммиту), а не от корня к текущему коммиту (как во всех других VCS).

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

Соответственно и дерева (которое куда-то там растёт) никакого нету. Есть просто набор изменений. А как Вы там для удобства их называете. И выстраиваете древовидные структуры – вообще не имеет никакого значения.

Если я работаю с головой. И добавляю сверху. Корня как такового нету. Есть только голова. И мои изменения. А точнее одна фиксация. И фиксация сверху неё. Дерево для этого не нужно. Дерево нужно, чтобы посмотреть что откуда растёт. А это и так прекрасно видно в Гите. Не вижу проблемы.

Я очень много работаю с ветвями. В том числе создавая временные ветви. И удаляя их тоннами. Без проблем. Никаких проблем с этим нету. Какой-то другой способ меня точно не устроит.

и на очень больших кодовых базах (60 MLoC+ как у Facebook), где много коммитов и много авторов, она не справляется.

Я подозреваю, что монорепа Google намного больше чем у Facebook, и при этом Google использует Git и их всё устраивает. Значит у Facebook руки кривые.

Да, отстой полный.

Аргументов не привели, а про проблему write amplification у git'а как-то умолчали. Как так?

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

«Абсурдно» - это то, что как раз из-за отсутствия нормальных именованных ветвей каждый коммит в Git начинается с того, что указывается тикет к которому он относится, иначе потом из истории это будет невозможно понять. Во всех командах, в которых я работал это делают. И это именно недостаток git, а не его преимущество.

Яндекс для своей монорепы рассматривал Mercurial, но в итоге они написали свою систему. Но им не нужен merge (что забавно) и пр.

Ещё одни неосиляторы, чего тут скажешь.

Все workflow уже готовы, на любой вкус.

и вокруг них постоянно идут споры..

Документация написана

тут согласен, документация хорошая.

Любой джун постигает необходимые команды для работы за два дня при правильном обучении

ну разве что названия выучить, не более того. Нюансы же работы команд, вообще редко кто знает (потому что документацию не читают).

Есть что-то, что делает весь процесс разработки лучше, чем Git? Нет.

IMHO, для команд, где не нужна распределенная разработка, переход на git не всегда целесообразен, если они уже работают на другой VCS. Если VCS нет, и нужно что-то бесплатное, то тут git выигрывает как де-факто стандарт.

А так у меня к git полно претензий. Отчасти совпадает с этим: https://www.sqlite.org/whynotgit.html

Яндекс для своей монорепы рассматривал Mercurial, но в итоге они написали свою систему. Но им не нужен merge (что забавно) и пр.

Не самый удачный аргумент приводить Яндекс и его говномонорепу в пример. Напомню – ту самую монорепу, которая утекла в даркнет и нанесла серьёзный дамаг как самому Яндексу, так и всем его клиентам, персональные данные которых отправились к «сотрудникам Сбербанка».

Идиотизм современных подходов к разработке не знает границ. Помню как даже на ЛОРе адепты этих монореп бегали в каждом треде, но когда Яндекс так эпично обкакунькался себе за шиворот, их число сильно поубавилось. Я не знаю, как можно не понять непреложную истину: с монорепой и доступом к ней кучи разрабов у тебя утечёт ВСЁ, с делегированными отдельными репозиториями у тебя утечёт только то к чему есть доступ у «источника».

Эти идиотские современные монорепы вот прямо-таки отдают той самой шизой ClearCase у крупных и насквозь корпоративно-проприетарных гигантов типа Motorola. Когда из-за одного человека «источники» получали доступ вообще ко всему до чего было не лень дотянуться.

Mozilla переводит разработку Firefox с Mercurial на Git

Разработчики из компании Mozilla объявили о решении прекратить использование для разработки Firefox системы управления версиями Mercurial в пользу Git. До сих пор проект предоставлял возможность использования Mercurial или Git на выбор разработчиков, но в основном репозитории применялся Mercurial. В связи с тем, что обеспечение поддержки сразу двух систем создаёт большую нагрузку на команды, отвечающие за сопровождение инфраструктуры, в будущем решено ограничиться применением для разработки только Git.

Источник: https://www.opennet.ru/opennews/art.shtml?num=60061

Я не знаю, как можно не понять непреложную истину: с монорепой и доступом к ней кучи разрабов у тебя утечёт ВСЁ, с делегированными отдельными репозиториями у тебя утечёт только то к чему есть доступ у «источника».

Ну слушай, вон у GameFreak (компании, которая разрабатывает серию Pokemon) пару месяцев назад ломанули внутреннюю сеть, дошли до GitLab и в результате утекли репозитории Git. Так что это проблема и без монорепы. :)

Помню об этом. Я просто привел как иллюстрацию что изредка так делают.

Аргументов не привели, а про проблему write amplification у git’а как-то умолчали. Как так?

Выдуманная проблема write amplification – это оправдания тормознутого Хэгэ. Не смогли в скорость. Попытались зайти с другой стороны. Вот и всё. М – маркетинг. Это как овсяные хлопья без асбеста.

«Абсурдно» - это то, что как раз из-за отсутствия нормальных именованных ветвей каждый коммит в Git начинается с того, что указывается тикет к которому он относится, иначе потом из истории это будет невозможно понять. Во всех командах, в которых я работал это делают. И это именно недостаток git, а не его преимущество.

Это делается через prepare-commit-msg хук. Это вообще делает тот, кто создаёт репу. Он кладёт туда все нужные хуки и install script с доком.

И это не недостаток. И не проблема. Фиксация есть фиксация. Была в одной ветви. Перешла в другую. Потом ветвь переименовали. Сделали перенос фиксации в другую ветвь. Потом всё залили в основную ветвь для разработки. Удалили оригинальную ветвь, т.к. она больше не нужна. Даже в истории.

Почему это должно как-то через ветки решаться, непонятно. При чём тут ветки? Хотите добавить к своей работе какую-то дополнительную информацию – ветка спешит на помощь? Но она тут совсем не при чём. У ветки есть своя функция – ветвление и слияние.

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

а как тикет связан с ветками? Что предлагается делать, если коммит бекпортируется в три параллельных stable релиза? Что делать если в ветке фиксы для нескольких разных тикетов?

Обычно работа построена так: разработчик получает задачу, создает ветку по номеру тикета, а-ля «feature/CODE-1234», «bugfix/CODE-1235» и т.д. Далее, при коммитах первым сообщением пишется «CODE-1234: реализовал что-то», «CODE-1235: исправил то-то». Потом, при пуше, JIRA/Phabricator/Bitbucket/GitLab подхватывают эти сообщения из коммита и ставят ссылки на багтрекер, а в багтрекере ставят ссылки коммиты в репозитории. Если коммит нужен в нескольких ветках, то он merge'ится или cherry-pick'ается. Проблема в том, что если сообщения не писать, то после merge'а «имя ветки» (=«reference») может быть удалено и потом по истории будет тяжело восстановить почему было сделано то или иное изменение. И без этих сообщений, blame/annotate становятся бесполезными, а с сообщениями ты можешь из blame/annotate зайти в багтрекер и посмотреть зачем было сделано прошлое изменение. И я не вижу ни одной причины, почему нельзя было сделать нормальные ветки, а не удаляемые в любой момент reference'ы.

почему нельзя было сделать клоунские ветки, а не удаляемые в любой момент reference’ы.

Перестаньте уже навешивать ветвям задачи, которые к ним отношения не имеют.

См.: https://github.com/janniks/prepare-commit-msg

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

Если это как-то и делать, то вероятно схоже с тем, как это сделано сейчас. В коммит пишутся теги Signed-off-by, Bug, Fixes и прочее. Наверное можно было бы сделать это не частью коммита, а, например, отдельной метой, обновляемой независимо. Но стоит ли этого добавленная сложность ваще неясно.

когда я начинал программировать лет 16 назад уже был git. мне сказать нечего. so slow

Это делается через prepare-commit-msg хук. Это вообще делает тот, кто создаёт репу. Он кладёт туда все нужные хуки и install script с доком

либо не делает. Если этого нет "из коробки, то значит дополнительные требования к квалификации настраивающего и время на развертывание.

И это не недостаток. И не проблема. Фиксация есть фиксация. Была в одной ветви. Перешла в другую. Потом ветвь переименовали. Сделали перенос фиксации в другую ветвь. Потом всё залили в основную ветвь для разработки. Удалили оригинальную ветвь, т.к. она больше не нужна. Даже в истории.

фиксации (подразумевались отдельные коммиты?) идут в рамках какой-то активности (bug, ticket, feature). Просматривая историю я хочу видеть все изменения в source control, относящиеся к этой активности.

Почему это должно как-то через ветки решаться, непонятно. При чём тут ветки? Хотите добавить к своей работе какую-то дополнительную информацию – ветка спешит на помощь?

Это специфика git, где ветка это ссылка на последний commit и не более того. В других VCS это сделано по другому. Например в mercurial это только одна из 3-х разновидностей веток. Т.е. имеются полноценые ветки, где информация о принадлежности к ветке известна по каждому коммиту.

Но она тут совсем не при чём. У ветки есть своя функция – ветвление и слияние.

А при просмотре истории ветка никакую роль уже не играет?

Я ничего не думаю, я чайник в сабже.

...тебе известно, самая прогрессивная UNIX-система NetBSD...

С этого момента поподробнее.

А как же git hist?

Как-то вот так:

| | * | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [2024-06-26] [1443b6ea806d] | arm64: dts: amlogic: setup hdmi system clock {{Jerome Brunet}} 

Это все правда как-то лучше тега Ticket: GH-1234, который так же можно вытащить в git log с помощью макроса?

А чё, прям писюн себе отрезал ржавым ножом и умер от заражения крови?

Вы, батенька, в Ядро чтоли вломились с этой компндой? Я такое только там наблюдаю. Ну ищщо в убуте, может.

Вы, батенька, в Ядро чтоли вломились с этой компндой? Я такое только там наблюдаю. Ну ищщо в убуте, может.

Ну вот представь такое теперь везде, потому что каждая ветка будет сохранена.

Так, это. Ветка ж по сути - отдельный коммит. Есть коммит - есть ветка, нет коммита - бывайте. Разве нет?

Так, это. Ветка ж по сути - отдельный коммит. Есть коммит - есть ветка, нет коммита - бывайте. Разве нет?

Если я правильно понял предложение автора, он предлагает вместо тега в описании коммита использовать имя ветки для определения тикета. Это породит бесконечное количество веток, которые всегда будут присутствовать.

это самое потрясающее что я видел на своём веку

Ээээ…

была команда админов только чтобы это говно поддерживать в рабочем состоянии

А, теперь я понял, в каком смысле было употреблено слово «потрясающее». :)))

На самом деле, у моих коллег, которые всё хотели пропихнуть закупку CC, был восторг от того, что мало того, что там версии контролируются, там ещё всё в графике и красивыми квадратиками! Учитывая, что на тот момент у нас ещё никакого VCS не было вообще, их в чём-то можно было понять.

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

Короче, за репозиторием следить надо. Иначе там так или иначе мусор будет.

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

Так все делают. Автор предлагает делать по-другому.

P.S. А, извини, я перепутал сабтреды :)))))

Я не очень понимаю суть предложения. Ты хочешь хранить ВСЕ ветки что когда-либо существовали? Но это же лютая помойка будет. Есть проекты где по тысяче тикетов в релиз.

Да, вполне себе вариант. Вам вообще-то не нужно знать о существовании этих веток и их количестве (как не нужно знать обо всех коммитах в истории). Плюс соглашении о наименовании веток, если таки нужно найти/отфильтровать ветку по названию.

И все это ради того чтобы три слова в коммит не написать?

Именно. Это должен быть встроенный (конечно настраиваемый, отключаемый) механизм, а не ручные манипуляции. VCS должна снимать нагрузку с пользователя и уменьшать роль человеческого фактора а не наоборот.

Не говоря уже о том что жто ломает тот flow, что есть в ядре.

Да и хрен с ним :-). Мы же сейчас не о linux kernel рассуждаем, а о VCS в принципе.

Если это как-то и делать, то вероятно схоже с тем, как это сделано сейчас. В коммит пишутся теги Signed-off-by, Bug, Fixes и прочее. Наверное можно было бы сделать это не частью коммита, а, например, отдельной метой, обновляемой независимо.

Угу, какие-то метаданные.

Но стоит ли этого добавленная сложность ваще неясно.

А Вы выйдите за рамки git и посмотрите, как это уже сделано в других VCS (opensource, про коммерческие даже не говорим): См. https://www.sqlite.org/whynotgit.html#git_does_not_track_historical_branch_names

Там ссылка на историю в git и в fossil. В fossil истории присутствует имя ветки, точка ветвления, вливания из upstream в ветку и точка слияния ветки в upstream.

Да, вполне себе вариант. Вам вообще-то не нужно знать о существовании этих веток и их количестве (как не нужно знать обо всех коммитах в истории). Плюс соглашении о наименовании веток, если таки нужно найти/отфильтровать ветку по названию.

У нас уже есть теги, они даже поддерживаются на уровне команд типа git-log. Чем это лучше?

Именно. Это должен быть встроенный (конечно настраиваемый, отключаемый) механизм, а не ручные манипуляции. VCS должна снимать нагрузку с пользователя и уменьшать роль человеческого фактора а не наоборот.

Так ты повышаешь нагрузку. Вот автор хочет называть ветки feature/GH-1234. А мы в проекте так не делаем, потому что это всрато и когда у тебя тридцать таких веток ты перестаешь понимать что происходит. Мы называем их feature/add-foobar. Все, у нас ломается трекер?

Да и хрен с ним :-). Мы же сейчас не о linux kernel рассуждаем, а о VCS в принципе.

Как это хрен с ним, если Linux – один из наиболее полезных пользователей Git?

Там ссылка на историю в git и в fossil. В fossil истории присутствует имя ветки, точка ветвления, вливания из upstream в ветку и точка слияния ветки в upstream.

Ты сейчас описываешь merge commit.

Вот, например:

$ git log
commit ca8626e84dee2e59f46f76ace75a24fab52cd0de (HEAD -> master)
Merge: f58c3fe 5013556
Author: gaylord <gaylord@localhost>
Date:   Tue Jan 7 13:15:16 2025 +0300

    Merge branch 'feature/add-something'

commit 5013556fc93d3a3af8d1949e526b59d51a433976
Author: gaylord <gaylord@localhost>
Date:   Tue Jan 7 13:14:34 2025 +0300

    readme: add something
    
    Ticket: EX-1

commit f58c3fe6178d313e5d060f58d0d6363c3af5b9a4
Author: gaylord <gaylord@localhost>
Date:   Tue Jan 7 13:14:16 2025 +0300

    Initial commit

$ git hist
*   [2025-01-07] [ca8626e] | Merge branch 'feature/add-something' []   (HEAD -> master)
|\  
| * [2025-01-07] [5013556] | readme: add something [EX-1]  
|/  
*   [2025-01-07] [f58c3fe] | Initial commit [] 

либо не делает. Если этого нет "из коробки, то значит дополнительные требования к квалификации настраивающего и время на развертывание.

Локально сделать не запрещено. Если сообщить кому-то там, что это его работа, религия не позволяет.

фиксации (подразумевались отдельные коммиты?) идут в рамках какой-то активности (bug, ticket, feature). Просматривая историю я хочу видеть все изменения в source control, относящиеся к этой активности.

К какой-то активности. А не к какой-то ветви. Зачем при этом ограничивать именование ветвей, ветвление и прочее? Смысла нет, просто в рамках какой-то из моделей разработки некоторым так кажется проще.

У нас уже есть теги, они даже поддерживаются на уровне команд типа git-log. Чем это лучше?

Хотя бы тем, что их нужно расставлять вручную.

Вот автор хочет называть ветки feature/GH-1234. А мы в проекте так не делаем, потому что это всрато и когда у тебя тридцать таких веток ты перестаешь понимать что происходит. Мы называем их feature/add-foobar. Все, у нас ломается трекер?

Это про распределенную разработку?

Хорошо, идентификатор ветки это вообще может быть uuid или что-нибудь в этом роде, который нужен для привязки коммитов к ветке. Человекочитаемое имя это не более чем изменяемый алиас. В приведенном примере при вливании в ваш проект алиас меняется на принятый в вашем проекте. Автор же может продолжать в своем репо/локальной копии использовать удобное ему имя. Я не вижу тут принципиальных препятствий.

Как это хрен с ним, если Linux – один из наиболее полезных пользователей Git?

Ох, значит linux kernel останется на удобном ему workflow.

Ты сейчас описываешь merge commit.

Так, а теперь посмотрим, всегда ли есть merge commit в истории?

Нет, при FF merge он не обязателен. Более того некоторые проекты (команды ) предпочитают rebase+FF merge (без merge commit) как основной вариант слияния веток.

Предположим merge commit есть. Можем ли мы в общем случае сказать, кто из его родительских коммитов upstream (trunk), а кто - вливаемая ветка? Нет, если правило «first parent - trunk» не выполняется.

И даже если все эти условия (наличие merge commit, first parent - trunk) выполнены, то имени ветки это нам все равно не даст.

Хотя бы тем, что их нужно расставлять вручную.

Так ветки тоже нужно называть вручную.

Хорошо, идентификатор ветки это вообще может быть uuid или что-нибудь в этом роде, который нужен для привязки коммитов к ветке. Человекочитаемое имя это не более чем изменяемый алиас. В приведенном примере при вливании в ваш проект алиас меняется на принятый в вашем проекте. Автор же может продолжать в своем репо/локальной копии использовать удобное ему имя. Я не вижу тут принципиальных препятствий.

Я вижу тут много разработки, какие-то ручные манипуляции и UUID. Вместо того, чтобы написать номер тикета в commit message.

Нет, при FF merge он не обязателен. Более того некоторые проекты (команды ) предпочитают rebase+FF merge (без merge commit) как основной вариант слияния веток.

Да, все так. Потому что им не важна история веток. Они ей и не пользуются. Тем кому важна, те пользуются. Все довольны.

И даже если все эти условия (наличие merge commit, first parent - trunk) выполнены, то имени ветки это нам все равно не даст

wut:

Merge branch ‘feature/add-something’

Тебе не кажется что ты пытаешь решить уже решенную (и довольно непротиворечивым способом) задачу с помощью дополнительной сложности, которая не особо добавляет удобства?

Локально сделать не запрещено.

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

Если сообщить кому-то там, что это его работа, религия не позволяет.

Проблема в тои, что условный мэйнтейнер git сервера может считать, что это именно не его работа, а задача VCS. А если VCS этого не делает «из коробки», то значит и не надо.

Зачем при этом ограничивать именование ветвей, ветвление и прочее?

Для веток обычно так и так есть какой-то naming convention. И более того права на ветки (если git server предоставляет средства access control) обычно привязываются к этим иерархическим именам.

По ветвлению я никаких ограничений не предлагал.

Как я понимаю, Вы предлагаете добавлять данные (метку «активности») непосредственно в текст комментария каждого коммита. Но ведь это по сути тоже ограничение. Для меня например текст комментария это человекочитаемый текст в произвольной форме. Всё остальное (идентификаторы багрепортов, тикетов и т.п.) должно быть в машиночитаемых метаданных (схема которых впрочем может быть гибкой и настраиваемой).

Как я понимаю, Вы предлагаете добавлять данные (метку «активности») непосредственно в текст комментария каждого коммита. Но ведь это по сути тоже ограничение. Для меня например текст комментария это человекочитаемый текст в произвольной форме. Всё остальное (идентификаторы багрепортов, тикетов и т.п.) должно быть в машиночитаемых метаданных (схема которых впрочем может быть гибкой и настраиваемой).

Оно и так в машиночитаемых данных. Серьезно, это однозначено решенные задачи, зачем их заново решать – решительно неясно.

Так ветки тоже нужно называть вручную.

угу, но это не то же самое, что каждый коммит помечать. И между прочим в fossil ветки реализованые как раз через тэги.

Branches are identified with tags. This means that check-ins can be freely moved between branches simply by altering their tags.

Отсюда https://fossil-scm.org/home/doc/trunk/www/branching.wiki

Я вижу тут много разработки, какие-то ручные манипуляции и UUID. Вместо того, чтобы написать номер тикета в commit message.

нет, ручных манипуляций тут как раз меньше. И почему ты решил что нужно минимизировать именно затраты на разработку VCS?

Да, все так. Потому что им не важна история веток. Они ей и не пользуются. Тем кому важна, те пользуются. Все довольны.

Ох, это хорошо, если это осознанный выбор, а не бездумное копирование чьего-то workflow из интернета. Я в конце комментария написал, как это бывает на практике.

wut:

Merge branch ‘feature/add-something’

И что? как мне поможет необязательный комментарий неопределенного формата в задаче автоматизировано извлечь информацию из истории?

И как я уже отметил ранее, хорошо, если этот merge commit вообще присутствует. А то ведь, могут предложить смотреть коммент к pull-реквесту, который вообще не является частью git истории.

Тебе не кажется что ты пытаешь решить уже решенную (и довольно непротиворечивым способом) задачу с помощью дополнительной сложности, которая не особо добавляет удобства?

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

На практике, когда команда мигрирует на git с другой VCS, никто к сожалению глубоко в нюансы git не вникает (в специфику веток и пр.). И ориентируются на свой предыдущий опыт. Т.е. про merge коммиты, first parent и пр. никто не знает и знать не хочет, потому что в других VCS все эти низкоуровневые «потроха» скрыты за удобным GUI (либо cmd UI).

Но работать-то надо, поэтому работа ведется, как есть. В лучшем случае ведутся какие-то вялотекущие обсуждения типа «а зачем нам merge commit, это лишний артефакт». Со всеми вытекающими последствиями для истории в VCS.

угу, но это не то же самое, что каждый коммит помечать. И между прочим в fossil ветки реализованые как раз через тэги.

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

нет, ручных манипуляций тут как раз меньше

У тебя UUID появился, конечно же их стало больше

И что? как мне поможет необязательный комментарий

Во-первых это дефолтное сообщение, во-вторых у тебя и ветки необязательные, можно всем дружно в мастер лить. Совсем-то с ума наверное сходить не надо?

неопределенного формата в задаче автоматизировано извлечь информацию из истории?

Во-первых это well-known формат, во-вторых почему бы и нет? Мы же на теги как-то полагаемся, а там, о ужас, имена неопределенного формата. А от них, меджу прочим, git-describe версию генерирует.

И как я уже отметил ранее, хорошо, если этот merge commit вообще присутствует. А то ведь, могут предложить смотреть коммент к pull-реквесту, который вообще не является частью git истории.

Опять же, я могу сделать один коммит Initial commit и все присылаемые мне изменения туда ребейзить. И будет у меня репозиторий с одним коммитом. А ещё можно изменения на десять тысяч строк мержить с описанием «small fixes». Повторюсь, что совсем с ума сходить не надо.

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

Так они предоставлены уже. GitHub, GitLab и прочее тем или иным образом работают с информацией из коммит мессенджей. Это работает даже через почту в ядре, все довольны.

Но работать-то надо, поэтому работа ведется, как есть. В лучшем случае ведутся какие-то вялотекущие обсуждения типа «а зачем нам merge commit, это лишний артефакт». Со всеми вытекающими последствиями для истории в VCS.

А эти последствия они вообще реальны для этих людей? У них есть задача искать по ветке точки слияния?

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

1. коммитер просто может забыть его поставить или поставить не тот.
2. тег можно снять и, насколько я помню, это не отражается в истории (только в ref log, но он привязан к серверу)
3. подобная схема должна быть утвержденна на уровне проекта, чтобы ее использовали все коммитеры, что само по себе непростая бюрократическая задача.

У тебя UUID появился, конечно же их стало больше

По умолчанию наследуется от родительского коммита (в предлагаемой мной схеме).

во-вторых у тебя и ветки необязательные, можно всем дружно в мастер лить. Совсем-то с ума наверное сходить не надо?

Во многих git-серверах есть встроенные средства ограничения доступа, как и gated checkin (pull request и пр). Вот с этим как раз всё относительно неплохо.

Во-первых это дефолтное сообщение, Во-первых это well-known формат, во-вторых почему бы и нет?

Это человекочитаемое сообщение причем по умолчанию (как ты сам отметил), т.е. зависит от конкретного git клиента или git сервера (если это pull request и merge был на стороне сервера).

Может быть где-то в документации в git (клиенту/серверу) описан этот well-known формат и даны гарантии по его неизменности? Вряд ли, скорее всего оно ещё кастомизируется и локализуется.

Мы же на теги как-то полагаемся, а там, о ужас, имена неопределенного формата. А от них, меджу прочим, git-describe версию генерирует.

Но git-describe не генерирует версию. Из документации:

Give an object a human readable name based on an available ref

The result is a «human-readable» object name which can also be used to identify the commit to other git commands.

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

Опять же, я могу сделать один коммит Initial commit и все присылаемые мне изменения туда ребейзить. И будет у меня репозиторий с одним коммитом. А ещё можно изменения на десять тысяч строк мержить с описанием «small fixes». Повторюсь, что совсем с ума сходить не надо.

Разделение логически разных изменений (как и внятное комментирование) - это зона ответственности коммитера. Сохранение информации о слиянии веток (что, куда, когда и кто) - это зона ответственности VCS. И если VCS этого не делает, либо делает ущербным образом, то это явно не в пользу VCS.

Так они предоставлены уже. GitHub, GitLab и прочее тем или иным образом работают с информацией из коммит мессенджей. Это работает даже через почту в ядре, все довольны.

Это информация для связи с багрепортами и прочими артефактами из bug/task трекера. Я же говорю, про историю коммитов в привязке к конкретным веткам. См. пример конце комментария.

А эти последствия они вообще реальны для этих людей?

Последствия затрагивают всех, работающих с этим репо.

Некоторым и VCS не нужен (достаточно папки с архивами исходников по датам) :-/

У них есть задача искать по ветке точки слияния?

Возьмём конкретный пример: есть upstream (trunk, master и т.п.) ветка куда вливаются только стабильные коммиты из условно фиче-веток (коммиты из которых тоже остаются в истории). Merge коммиты присутствуют не всегда. Нужно взять из этой стабильной ветки несколько версий кода месячной давности для экспериментов (не зацепив при этом коммиты из фиче-веток). Как это сделать используя только git log?

Так ты повышаешь нагрузку. Вот автор хочет называть ветки feature/GH-1234. А мы в проекте так не делаем, потому что это всрато и когда у тебя тридцать таких веток ты перестаешь понимать что происходит. Мы называем их feature/add-foobar. Все, у нас ломается трекер?

Use case, с которым я неоднократно сталкивался: в команде 2 разработчика делают 2 фичи. В какой-то момент выясняется, что одна фича зависит от другой и хорошо как-то вместе всё закончить, прежде чем произойдет влитие в релизную ветку. Во время стендапа разработчик говорит «О! Я делаю это в рамках тикета CODE-1236» и тот, кому фича нужна знает, что ему нужно ответвиться (или влить к себе) от «feature/CODE-1236». Нет, трекер от этого не ломается, но при таком наименовании это можно сделать сразу из IDE или CLI без необходимости посещения багтрекера и выяснения как именно называется ветка.

коммитер просто может забыть его поставить или поставить не тот.

Коммитер в ветку может поставить не то. Все что человек вводит, он может ввести не так.

тег можно снять и, насколько я помню, это не отражается в истории (только в ref log, но он привязан к серверу)

Артефакты, от него нагенеренные, уже лежат в репозитории. Их придется убирать.

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

Это чрезвычайно тривиальная задача, она буквально везде решена. Вот где угодно: BitBucket, GitHub, GitLab, Forgejo, LKML. Все справились.

По умолчанию наследуется от родительского коммита (в предлагаемой мной схеме).

Так проблема не в этом, проблема в том что теперь у тебя вместо одной сущности (имя ветки) их две.

Во многих git-серверах есть встроенные средства ограничения доступа, как и gated checkin (pull request и пр). Вот с этим как раз всё относительно неплохо.

Точно тем же механизмом проверяется валидность коммитов. Это один и тот же механизм hooks.

Но git-describe не генерирует версию.

Генерирует. Куча проектов этим пользуется.

Разделение логически разных изменений (как и внятное комментирование) - это зона ответственности коммитера. Сохранение информации о слиянии веток (что, куда, когда и кто) - это зона ответственности VCS. И если VCS этого не делает, либо делает ущербным образом, то это явно не в пользу VCS.

При условии, что у тебя стратегия merge PR контролируется на стороне UI для мержа и там ты можешь форсить любую политику, какую тебе захочется. Так что если тебе в проекте нужно, чтобы у тебя были MR, это контролируется галкой в UI.

Это информация для связи с багрепортами и прочими артефактами из bug/task трекера. Я же говорю, про историю коммитов в привязке к конкретным веткам. См. пример конце комментария.

Так бога ради, мы уже установили, что зафорсить правильную историю в Git это один клик в UI.

Последствия затрагивают всех, работающих с этим репо.

Возьмём конкретный пример: есть upstream (trunk, master и т.п.) ветка куда вливаются только стабильные коммиты из условно фиче-веток (коммиты из которых тоже остаются в истории). Merge коммиты присутствуют не всегда. Нужно взять из этой стабильной ветки несколько версий кода месячной давности для экспериментов (не зацепив при этом коммиты из фиче-веток). Как это сделать используя только git log?

Что значит не всегда? Галка в UI стоит, принятие PR всегда вырождается в git merge --no-ff на стороне сервера. Все работает, господи, ты придумываешь проблемы просто на пустом месте. Если мы говорим про email-based workflow, посмотри, как это Линус делает. У него тоже все прекрасно работает.

Когда мы начинаем уходить в сторону «ну вот разработчики пользуются тулзой неправильно», мы уходим не туда. Если разработчики не пользуются тулзой правильно и процессы у них всратые, то нет никаких веток, есть мастер с кучей коммитов «fix things lol» по пять тыщ строк.