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

Они что, не знают о Fossil?! Просто для комплекта нужно добавить.

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

https://mail-index.netbsd.org/tech-repository/2024/06/06/msg000804.html

Если в проекте столько идиотов-ретроградов что медленный, неудобный и вообще мёртвый меркуриал вообще рассматривался как вариант, оставались бы на CVS, делов-то. А так, конечно, если им интереснее не ОС разрабатывать, а городить конверторы между VCS, флаг в руки.

Или стоит уже наконец отказаться от git и перейти на Mercurial?

Развивай мысль дальше и двигайся к CVS. А смузи-хлёбы пусть лучше лялих ломают.

В OpenBSD пилят got ибо git тоже сосёт и не укладывается в модель разработки.

Если в проекте столько идиотов-ретроградов что медленный, неудобный и вообще мёртвый меркуриал вообще рассматривался как вариант, оставались бы на CVS, делов-то.

Анон, ты не поверишь, но Mercurial ещё жив. Я тоже не поверил вот, когда недавно узнал об этом. С тех пор, как их ведущий разраб транснулся, отрезал себе член и ушёл из проекта, дела у них стали чуть получше. Возможно, как-то связано.

В OpenBSD пилят got ибо git тоже сосёт и не укладывается в модель разработки.

Так got это просто другой cli к git. На редкость бессмысленная история.

Развивай мысль дальше и двигайся к CVS.

Так CVS сосёт. Это всем известно уже давно.

В OpenBSD пилят got ибо git тоже сосёт и не укладывается в модель разработки.

Мне кажется, got пилят по какой-то другой причине. У OpenBSD вообще очень своеобразная тусовка сложилась.

Это больше эмуляция CVS workflow поверх Git потрохов.

Да, но какой в этом смысл? Это жуткое карго-культирование. У людей в системе lsblk нет и файловая система данные через ребут теряет, а они страдают что в git команды другие и их учить надо.

Мне кажется, got пилят по какой-то другой причине.

См. чуть выше – сохранение CVS workflow (в частности email-based patches), но с другими потрохами.

в частности email-based patches

Это полная шиза, git все это умеет из коробки: git send-email HEAD~3

Да, но какой в этом смысл?

Как и весь OpenBSD проект – дяди делают то, что их прёт, для себя любимых. Никакой инклюзивности. Не нравится – иди мимо.

Не нравится – иди мимо

Все так, от них поэтому уже разработчики уходят. OpenBSD совершенно неактуальная ОС потому что все люди которые пилили что-то реально нужное оттуда ушли, остались только динозавры, которые пилят странное.

Скажи, ЛОР, что ты думаешь по этому поводу?

Не делать выбора – делать выбор в пользу своей бесхребетности. Они его сделали.

Может ли подобный подход работать в других проектах?

Лишние проблемы никому не нужны. То есть нет.

Или стоит уже наконец отказаться от git и перейти на Mercurial?

Отказаться от Ртути. В ней нет смысла.

Отказаться от Ртути. В ней нет смысла.

Как и в гите, тащемта. Но у hg есть пара приятных плюшек типа трекинга переименований файлов, что очень и очень приятно, потому что в гите они напрочь ломают историю.

git log —follow или опция log.follow, чтобы сделать это дефолтом.

Как и в гите, тащемта. Но у hg есть пара приятных плюшек типа трекинга переименований файлов, что очень и очень приятно, потому что в гите они напрочь ломают историю.

Знаем-знаем, в svn они тоже были. Только все делали cp вместо svn cp и историю таки теряли. А в git есть --follow, который работает хотел того перемещающий файл или нет, забыл он специальную команду или нет.

git log —follow

Оно пытается угадать на основе сходства двух файлов. Там есть параметр similarity, по умолчанию равный 100 (процентам). В самих метаданных у гита отслеживания переименований нет, поэтому если ты в рамках коммита переименовал и подправил файл, гиту оторвёт жопу.

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

В OpenBSD пилят got ибо git тоже сосёт и не укладывается в модель разработки.

У них там что-то непонятное.

Got uses Git repositories to store versioned data.

It will always remain possible to work with both Got and Git on the same repository.

Можно, конечно. Тем не менее, переименовать файл с одновременной правкой – довольно частая ситуация. И я бы хотел, чтобы система контроля версий помогала это отслеживать и не вижу ни одной причины, почему она не должна это уметь, кроме «так исторически сложилось».

Там другой интерфейс. Например, нет stage. Который удобен, чтобы разбить большое изменение на отдельные коммиты, чтобы ревью было проще делать.

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

чем метаться между двумя системами контроля версий.

Лулз конечно в том, что метаться уже не надо. Они по большей части совместимы через тулзы типа вышеупомянутого git-cinnabar. Локально ты можешь использовать что угодно, твои коллеги не заметят разницы.

Ситуация в принципе напоминает когда я лет 10 назад работал в компании, использовавшей Subversion, но только я им пользовался через git-svn, потому что сам svn я предпочту избегать всеми силами.

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

Это потому что SVN сосёт. Между git и hg такой проблемы вроде как нет.

Впрочем, уже есть hg-подобный фронт для git, называется jj.

Как и в гите, тащемта.

Как без Гита жить не знаю.

hg

Может там что-то есть. Не помню чтобы нужно было.

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

А, ну да, говорят, что Ртуть намного тормознее ввиду своего внутреннего устройства. Как говорил Линус: «Гит делает это лучше», имея ввиду производительность.

Как без Гита жить не знаю.

skill issue lmao

А, ну да, говорят, что Ртуть намного тормознее ввиду своего внутреннего устройства. Как говорил Линус: «Гит делает это лучше», имея ввиду производительность.

Ну, так и было. Году в 2008. С тех пор прошло уже 17 лет, чувак. Внезапно с тех пор всё поменялось, в том числе благодаря упёртости авторов git.

и не вижу ни одной причины, почему она не должна это уметь

Там просто не работа с файлами. А работа со всей директорией закатаной в блоб. Файла как сущности нету. Просто отметка в блобе, что этот кусок взят из файла такого-то.

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

Например, нет stage.

This is a synonym for git-add[1]. Please refer to the documentation of that command.

Нет add? Всё или ничего?

Анон, ты не поверишь, но Mercurial ещё жив. Я тоже не поверил вот, когда недавно узнал об этом. С тех пор, как их ведущий разраб транснулся, отрезал себе член и ушёл из проекта, дела у них стали чуть получше. Возможно, как-то связано.

Ты о разработке? Потому что я нет. Горстка нетакихкаквсехов может свои «ещё живые» недоvcs - хоть hg, хоть фоссил, хоть сраные пихули, в стол сколько их душонкам угодно, в реальном мире их нет и никогда не будет.

Будучи мантейнером четырёх сотен разношёрстных пакетов и вдобавок периодически причёсывая сотни чужих и бесхозных пакетов в ажно трёх репозиториях, постоянно что-то отправляю во всевозможные апстримы. Приходилось пользоваться и bzr с этим их lp: и darcs и arch и бог весть чем ещё. Но только не последние годы, даже не помню уже сколько - 2, 5 или 10. Потому что этот зоопарк кончился, и существует VCS наголову их превосходящая технически и по UX. Не утверждаю, конечно, что идеальная, но ни одна из поделок пока не продемонстрировала ни то что киллер фичи, но хотя бы даже того что просто хотелось бы потыкать. А для неосиляторов cli интерфейса которых мне никогда, наверное, не понять, есть мордочки типа got и gitless или интеграция в мышевозюкательные IDE.

Причём я вполне допускаю что проекты не в git таки кто-то даже ведёт, но вот на публику они не попадают, и это ожидаемо, потому что делаются такими же нетакиекаквсехами, а им не нужна публичность, они ковыряются «в стол», и нетаковость у них идёт комплексом - там и лицензия своя, естественно несвободная, зато «нельзя использовать русским» ради всеобщего блага, и язык какой-нибудь выродок типа hare или zig, и сборка, не знаю, на каком-нибудь waf или premake. Да и пилите на здоровье, родимые. Только есть чёткая грань между вашим манямирком, и СПО-сообществом ведущим коллективную разработку коллективно использующегося софта.

Да, ты можешь добавить только файл целиком.

Ну, так и было. Году в 2008. С тех пор прошло уже 17 лет, чувак. Внезапно с тех пор всё поменялось, в том числе благодаря упёртости авторов git.

В данном случае авторы Гита поступили верно. А Ртуть потокает дегенеративным разрушениям мозга разработчиков из ФБ. И я лично не против, пока этот рак не расползается.

Дегенераты из Майкрософт запилили свой комбайн поверх Гита. Не помню как называется.

У кого-то из них (вроде б у ФБ), есть ещё дегенеративное требование фиксировать минимальные изменения и отправлять в основную репу. Видимо это аналог совместного редактирования Гугл-документа, только репозитория. Гигантского. Одного для всех. И там реально тысячи коммитов в секунду прилетают.

То что Гит не пытается в эту дегенерацию – хорошо. Ещё один повод его использовать.

Выполнение базовых команд затрагивающих проект целиком всё равно у Гита быстрее. Потому что он прост, как топор (что следует из названия).

Фишка там в том, что это git с CVS workflow: https://gameoftrees.org/comparison.html

Может ли подобный подход работать в других проектах?

У фрибсд 12-я ветка по факту так и хранится - две репы svn+git с взаимной синхронизацией.

Или стоит уже наконец отказаться от git и перейти на Mercurial?

Стоило перейти на свн вместо этих двух.

Там просто не работа с файлами. А работа со всей директорией закатаной в блоб. Файла как сущности нету. Просто отметка в блобе, что этот кусок взят из файла такого-то.

Да и насрать? То, что отсутствии фичи обусловлено проблемой изначального дизайна модели данных и невозможностью её безболезенной смены, не делает ситуацию как-то лучше.

В данном случае авторы Гита поступили верно. А Ртуть потокает дегенеративным разрушениям мозга разработчиков из ФБ. И я лично не против, пока этот рак не расползается.

Нет. Они потом сами локти кусали и запиливали себе похожее, но уже без сторонней помощи.

То что Гит не пытается в эту дегенерацию – хорошо. Ещё один повод его использовать.

Гит её не только пытается, но и сам иногда придумывает.

Выполнение базовых команд затрагивающих проект целиком всё равно у Гита быстрее. Потому что он прост, как топор (что следует из названия).

Честно говоря, я не вижу большой разницы. Она может быть при репозитариях масштаба упомянутых тобой компаний, но я там не работаю и работать не планирую. В проектах, с которыми я работаю, скорость обоих примерно одинакова и особо погоды не делает.

Потому что он прост, как топор (что следует из названия).

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

С другой стороны, а является ли это плюсом? Ты же код пишешь небось в каком-нибудь vscode, а не в notepad.exe.

Оно пытается угадать на основе сходства двух файлов

Спасибо, это я тебе про это рассказываю, не ты мне.

Там есть параметр similarity, по умолчанию равный 100 (процентам)

Неправда

The default similarity index is 50%.

В самих метаданных у гита отслеживания переименований нет, поэтому если ты в рамках коммита переименовал и подправил файл, гиту оторвёт жопу.

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

Нет, понятно что в обоих подходах есть определённый смысл, но работает на практике только --follow. Как явный подход не работал в svn я имел удовольствие наблюдать и на мегарепе яндекса, и во FreeBSD’шных репах src и ports, и ещё в нескольких коммерческих и свободных проектах.

The default similarity index is 50%.

А, уже? Мне казалось, было 100. Ну да ладно, не так важно.

Как явный подход не работал в svn я имел удовольствие наблюдать и на мегарепе яндекса, и во FreeBSD’шных репах src и ports, и ещё в нескольких коммерческих и свободных проектах.

Ты не думаешь, что это проблема svn больше чем такого подхода, анон? Так-то я видел, когда вместо git mv делали просто mv и забывали добавить новый файл в индекс, тупо жамкнув по «Deleted: …» в своей IDE, из-за чего считался удалённым. Что то говно, что то, ей богу.

Тред не читай сразу отвечай.

Гит худшая из существующих систем контроля версий. Но поскольку была первая из модных молодежных на замену свн и цвс сейчас все на ней.

Хг тупа нинужна.

git с CVS workflow

Да, видимо разработка ОС – совсем скучное занятие.

Пора концепцию патчей по электронной почте пересмотреть.

Ну, так и было. Году в 2008. С тех пор прошло уже 17 лет, чувак. Внезапно с тех пор всё поменялось, в том числе благодаря упёртости авторов git.

Facebook с его очень специфичным кейсом пусть for the love of god пользует hg, вместо того чтобы костыли для него тащить в git. От этого ни hg популярнее не станет, ни git хуже.

А для не-facebook за эти 17 лет не изменилось ничего, можешь сконвертить какую-нибудь большую репу и потестировать на ней типовые операции и сравнить с бенчами 20летней давности, а вообще это даже упёртые фанатики уже перестали пытаться делать. Изначально ущербная архитектура репозитория не менялась, с питона hg не переписали, а питон быстрее не стал. Сыграю на твоей стороне - если что, прямо в сейчас в питон наконец-то впиливают jit, поэтому hg станет на десятки процентов быстрее. Увы, отрыв не сильно сократится.

Считаю, что это хорошо.

свн

«Сделано по уму CVS».

Это на нём вроде code.google.com работал? Тормозная неудобная штука даже если просто нужно склонить репу.

Facebook с его очень специфичным кейсом пусть for the love of god пользует hg, вместо того чтобы костыли для него тащить в git. От этого ни hg популярнее не станет, ни git хуже.

Вообще, я не считаю git прямо убогим. Кроме трекинга переименований и ещё пары мелких нюансов, у меня особых претензий нет. Но так же у меня их нет и к Mercurial. Причина популярности git лежит абсолютно за пределами технической плоскости, так-то. Если бы вместо гитхаба 15 лет назад победил битбакет, ты бы точно так же сейчас защищал прелести hg.

Изначально ущербная архитектура репозитория не менялась, с питона hg не переписали, а питон быстрее не стал

Я напомню, что почти 40% гита написано на баше. Раньше там ещё дофига перла было, но переписали на Си как раз из-за скорости.

не знаю на чём работало code.google.com, у меня на свн работает моя репа.

склонить репу.

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

Ты не думаешь, что это проблема svn больше чем такого подхода, анон?

С чего мне так думать? svn была какое-то время самой популярной vcs, и там явно пометить svn mv/cp был проще простого. Просто приписать 4 символа к cp/mv. Проще нельзя в принципе. И это не работало. Мне кажется это более чем показательно.

Так-то я видел, когда вместо git mv делали просто mv и забывали добавить новый файл в индекс, тупо жамкнув по «Deleted: …» в своей IDE, из-за чего считался удалённым.

И что ты этим хотел сказать? Это поведение одинаково с любой vcs. Мы говорим о разном поведении. Где в одном подходе историю можно потерять забыв сделать команду, а в другом нельзя как бы ты не пытался.

Просто приписать 4 символа к cp/mv. Проще нельзя в принципе. И это не работало. Мне кажется это более чем показательно.

Пользователи svn были вообще особой кастой. Я до сих пор пытаюсь понять, что это вообще было и почему оно было таким убогим и всратым. Возможно, svn повреждает мозг. Firkax выше является неплохим примером подобного.

И что ты этим хотел сказать?

Я хочу сказать, что косяков, вызванных этим, я видел тоже достаточно. Так что, повторюсь, «что одно говно, что другое». Обосраться на ровном месте вообще не сложно.

Причина популярности git лежит абсолютно за пределами технической плоскости, так-то. Если бы вместо гитхаба 15 лет назад победил битбакет, ты бы точно так же сейчас защищал прелести hg.

Слышали мы и эту мантру. После той, конечно, где линус выкинул двадцатку на харизму, кастанул на всё сообщество charm и они только ради него вместо конфетки hg выбрали какашку git. Нет, всё просто, и не надо оправдания искать - git победил просто тем что он лучше.

Я напомню, что почти 40% гита написано на баше. Раньше там ещё дофига перла было, но переписали на Си как раз из-за скорости.

И что?

После той, конечно, где линус выкинул двадцатку на харизму, кастанул на всё сообщество charm и они только ради него вместо конфетки hg выбрали какашку git. Нет, всё просто, и не надо оправдания искать - git победил просто тем что он лучше.

Харизма Линуса тут особо не причём. Но то, что самый жирный открытый проект на Си использовал git, безусловно повлияло. Вторым фактором же был, конечно же, GitHub, который значительно опережал по удобству BitBucket. Не говоря уже о древних кусках навоза типа Google Code и SourceForge.

Да и насрать? То, что отсутствии фичи обусловлено проблемой изначального дизайна модели данных и невозможностью её безболезенной смены, не делает ситуацию как-то лучше.

Я могу diff посмотреть. И из какого это файла 100 лет назад пришло и как он назывался тогда – это то, что мне точно не нужно.

А вот перемещение функции в рамках одной фиксации – иногда удобно.

Если Вам нужно знать историю переименования файла – то это какая-то сторонняя проблема. Ну назывался он иначе, и зачем это знать?

Нет. Они потом сами локти кусали и запиливали себе похожее, но уже без сторонней помощи.

У них всё ещё репа не должна превышать 1ГБ, чтобы считаться здоровым. Возможно есть какие-то инструменты поверх. Ну и ладно.

В проектах, с которыми я работаю, скорость обоих примерно одинакова и особо погоды не делает.

Это верно. С появлением NVMe и уходом вращающихся дисков (куда им и дорога), заметить разницу нереально.

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

У него ядро простое как топор. Остальное всё сверху навешано.

С другой стороны, а является ли это плюсом? Ты же код пишешь небось в каком-нибудь vscode, а не в notepad.exe.

Да, с точки зрения отказоустойчивости и проверки целостности (включая защиту от подлога).

Там ядро простое. Изначально это вообще было 80 строк кода – закатать в блоб, вычислить SHA1, поместить этот блоб куда-то там.

Пока в этот процесс не добавляются усложнения, нет проблемы. А если что-то делается сверху – я не против. Пусть машина работает.

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