После трёх месяцев разработки опубликован выпуск распределенной системы управления исходными текстами Git 2.44. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Код Git распространяется под лицензией GPLv2+...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60659
Гит пора заносить в Парижскую палату мер и весов в категории "когда коту делать нечего".Такого награмождения фич, нужных 0,3 анониму нету нигде. Гит сожрёт сам себя.
Ну почему развитие продукта идет исключительно по пути дальнейшего "награмождения фич"?
Почему отсутствуют новости типа:
- оптимизирована работа с памятью;
- добавлена поддержка аппаратных инструкций;
- критичные функции переписаны на asm/rust;
- произведена чистка кодовой базы;
и т.п.?
Потому что проект не стагнирует, а перечисленное тобой верный симптом умирания.
Перечисленное мной - симптомы зрелости (production ready).
А ты, похоже, путаешь "не стагнирует" с подростковым энтузиазмом.
Ты подменяешь понятия. Мамонтовость и окаменелость не является зрелостью, и уж тем более они не являются пригодностью к применению в коммерческих продуктах. Сегодня продакшен-реди это когда развитие не прекращается и проект сохраняет актуальность, по возможности избегая слишком кардинальных изменений. В случае с гитом же, виден общий вектор развития, нацеленный на применение в практической разработке, там, где исходники на сотни и тысячи гигабайт.
>продакшен-реди это когда развитие не прекращается и проект сохраняет актуальностьКак, например, в ядре вносят порчу фс или в систем-д - затирание биоса? Сохраняет актуальность, что и не говори.
>исходники на сотни и тысячи гигабайт
Модульность и стабильность АПИ между компонентами Н.Е_Н.У.Ж.Н.О?
> оптимизирована работа с памятью;
> добавлена поддержка аппаратных инструкций;
> критичные функции переписаны на asm/rust;
> произведена чистка кодовой базы;Это ты ВОТ ЭТО называешь "Мамонтовость и окаменелость"?
Поколение Айфона...
Это глупости, в нормальном проекте подобное где-то в самом конце списка приоритетов. Если будет актуально, будет применено вместе с реальными улучшениями.
Вот вам и ответ, почему так упало качество ПО.
> Вот вам и ответ, почему так упало качество ПО.ПО никогда не было качественным, что ты фантазируешь? Относительно чего оно могло упасть? Наоборот, значительно выросла сложность и, несмотря на это, существенно возросло качество.
Мелкомягкое ПО редко когда было качественным. Но сейчас стало ещё хуже.Качество результата, у тех же, например, упало. Речь про конечный измеримый результат, а не объяснения про объективные сложности у работника.
>production readyНичего более production ready, чем Git, которым пользуется почти весь прод и представить нельзя. То что там добавили пару новых фич, не ломая старых - не имеет значения. 99% не заметят разницы.
>пользуется почти весь продУгадай с трех раз, почему реальный прод (RHEL, Ubuntu etc) до сих пор использует версии git 2.25
>>пользуется почти весь прод
> Угадай с трех раз, почему реальный прод (RHEL, Ubuntu etc) до сих
> пор использует версии git 2.25Наверное, потому что никто не кодит софт на серваках, например :P.
> Угадай с трех раз, почему реальный прод (RHEL, Ubuntu etc) до сих пор использует версии git 2.25$ git --version
git version 2.34.1Ubuntu 22.04
RHEL не проверял. Но если и так, то скорее всего потому, что на момент релиза актуальная версия была именно такая.
> Угадай с трех раз, почему реальный прод (RHEL, Ubuntu etc) до сих пор использует версии git 2.25Т.к. они используют целиком дистрибутив с комплектным софтом из репо, проверенным на работоспособность. Не занимаются точечным обновлением пакетов, т.к. не рискуют нарваться на баги, для которых неизвестны способы обхода.
А вот когда обновят дистр., то и версии помолодеют.
В проде вообще хорошо, когда поменьше обновлений. Меньше вероятность схлопотать чужую и ненужную недодумку.
> Перечисленное мной
> переписаны на Rust
> с подростковым энтузиазмомА завтра ты новый язык выучишь, и опять всё переписывать?
Есстесственно! И не по одному разу!
> - добавлена поддержка аппаратных инструкций;
> - критичные функции переписаны на asm/rust;Спасибо, не надо.
>- критичные функции переписаны на asm/rust;Переписать критичную функцию на языке с нестабильным синтаксисом, тянущим тысячу лефтпадов через карго культ в проект. Отличный план. Кто это повторит - не забудьте: минорный релиз должен быть.
Предполагаю, что развитие _этого_ продукта нужно вот 0,3 анонимам - а все полезное пилится где-то в гитхабе\лабе\IDE...
> - критичные функции переписаны на asm/rust;А как же безопасная работа с памятью в асме? Тогда уж лучше, чем "- критичные функции переписаны на asm" потому что раст и так написан на C
Как? Неужеди Git стал сложнее высшей математики?
> нету нигде.Есть fossil, где помимо вот этого всего всего ещё и вебморда уровня gitea из коробки
Просто ты совершенно не понимаешь что происходит и какие есть проблемы у git
Лишь бы на SHA256 не переходить.
шо?
Я бы даже предпочёл переход на BLAKE3.
Система управления, да ещё "исходными текстами" это новость про картотеку?
>Добавлена поддержка системы непрерывной интеграции GitLab CI.Ну то есть раньше было гит=гитхаб, а сейчас гит=гитлаб. Кушайте, не обляпайтесь, подсаживайтесь на сервис.
По ссылочке-то пройди. К исходникам гита добавили yaml-файл для гитлаб-ци, если кому-то зачем-то понадобится собрать гит из исходников при помощи гитлаб-ци.
Тебе ли не пофиг в чём не разбираться?
Я не успеваю изучить и опробовать новые фичи, как вдруг выкатывают новый релиз...
Старость конечно не радость.
Главное что основные работают. Зачем все попробовать? Соевый что ли?
Я недавно нашел fixup/autosquash фичу и удивлялся почему она не работает с неинтерактивным rebase. А тут это как раз исправили, замечательно! А на новые фичи пофиг
И по-прежнему hg проще и понятнее, а самое главное — системно более строже и логичнее.
Что там с rhg? Обещали лютый прирост скорости (ну, после питона-то).
Если hg запускается 0 раз, то перфоманс увеличивается до бесконечности, учи математику
Когда интернет-троллинг скатился до такого дна? Почему мегаумы прошлых лет уступили место очкасто-прыщавым в плохом смысле зaдpoтaм, которые шамкая недоразвитой челюстью выдают такой уровень «иронии», достойной разве что веганских пабликов?Как производительность хорошего, но не очень распиаренного продукта кореллирует с его количеством запусков? Ты реально настолько туп, что для тебя это логично и даже смешно? Ты наркоман?
Напрямую коррелирует. Почитай кто здесь переписал бэкенд merge и rebase? У кого их миллионы, а может сотни миллионов в день?Ещё раз хорошенько подумай.
Пайтон тут причем, если упор чисто в io?
Жаловались, что беда была именно в этом. Я нутро ртути не изучал, заявлять однозначно не могу, но помню что ртуть переписывать брался фейсбук (чем кончилось — хз, может прикопали, а может у себя пользуют), и что rhg вроде как ощутимо быстрее.Вторым пунктом, на который традиционно жалуются смузикодеры с гита — отсутствие из коробки возможности откатить коммит (ребэйс, кажись). Но во-первых её можно было плагином доустановить, а во-вторых она противоречит принципам ртути — что все изменения должны фиксироваться, и если кто-то закоммитил фигню, то должен следом слать исправляющий коммит, дабы журнал всё фиксировал и сохранялась однозначность веток-цепочек.
> она противоречит принципам ртутиЕсли принципы инструмента идут вразрез с принципами пользователей, то инструмент идёт нафиг.
Это к вопросу "почему hg менее популярен, чем git."
> если кто-то закоммитил фигню, то должен следом слать исправляющий коммит, дабы журнал всё фиксировал и сохранялась однозначность веток-цепочек.Из известных мне трёх случаев намеренного отказа от hg в двух именно это было причиной (и ещё неудаляемые ветки). Нужно понимать что VCS - это не система аудита, она не только не обязана хранить вообще _каждое_ изменение и ветку, она обязана этот временный мусор НЕ хранить. Кроме этого, большинство разработчиков пришло к пониманию удобства линейной истории в основной ветке. Поэтому rebase, как для того чтобы работу в feature branch полностью переколбасить и разбить на topic коммиты, в которых видны не эксперименты, потуги и причесывание фичи, а её внедрение по осмысленным этапам, и rebase для того чтобы эту работу перенести в основную ветку - это обязательная, базовая функциональность VCS. Системы не умеющие этого из коробки идут на свалку истории, а системы которые не просто этого не умеют, но у которых "приниципы" этого не уметь вообще можно только обоccать.
> жалуются смузикодеры с гита
Какие же вы смешные. git - это промышленный стандарт. Радужные небинарные смузикодеры - это как раз mercurial, fossil и прочие пихули с darcs'ами.
Вечно мутирующая система стандартом быть не может.
То, что её безальтернативно продвигают, как и линукс — это другой вопрос.
Кто продвигает? Не иначе как массоны и всемирный заговор?
Масоны пишутся с одной С.
Очень согласен с основными мыслями поста.И добавлю, что
> неудаляемые ветки
в Меркуриале таки отсутствуют, как и в Git, как и в SVN, как и в CVS.
> в Меркуриале таки отсутствуют, как и в Git, как и в SVN, как и в CVS.Ложь. Удалить ветку в Git не проблема.
Перечитай пост, на который отвечаешь, а то у тебя взаимоисключающие предложения.
Фатальный недостаток. Хотя, если исправляется плагином - то норм.
Понимаешь, бывает что обколюсь и начну коммитить. Сами изменения я сделал ранее, когда был в адеквате, а вот коммит делаю уже намухоморенным. Предохранитель канеш сработал не отправить на сервер, но вот смотрю я историю коммитов, и вижу что пять коммитов назад я писал такую чухню, что не дай господь. Вот как мне переписать коммит сообщение? Не код, с ним все в порядке. Только сообщение.
ну и зачем в истории куча мусора, которая нужна была только для того, чтобы фиксировать какие-то промежуточные идеи и состояния
Но hg никто не хочет поддерживать и нет ничего даже отдалённо напоминающего gitlab. И даже в ide всё чаше hg поломанное/глючит. Так выглядит умирание.Хотя фич hg хватит 90% разрабов на 95% проектах.
> Но hg никто не хочет поддерживать и нет ничего даже отдалённо напоминающего gitlab.Потому что питоняши накидали как обычно - хаотичное месиво, без намека на архитектуру, с единственным достоинством - пытается замаскировать штурвал аэробуса под привычные вожжи. Да еще гуи всякие для подобных по смыслу гроссмейстеров.
Поскольку "гроссмейстеры" которые вожжи выпустить из рук не могут звезд с неба в програмизме не хватают, их и уходят нафиг из приличных мест. Вместе с этой штукой. Кому нужен необучаемый дев и горбатый девтул?!
> И даже в ide всё чаше hg поломанное/глючит. Так выглядит умирание.
Потому что нагамнякали абы что и абы как. Когда заметили что работает "не очень" - начались метания. И как подобный мусор поддерживать если его весь постоянно панически перетрясают?
> Хотя фич hg хватит 90% разрабов на 95% проектах.
Это как сказать что бричек хватит на 90% оказий и 95% дорог.
Когда важный инструмент для процесса разработки ПО постоянно обновляется, это наводит на неприятные мысли о высокой вероятности хлебнуть нешуточных проблем с целостностью хранилища. Для серьёзных ответственных дел такое не годится. Правильно кто-то написал, что давно пора было сделать простой и понятный инструмент, отладить и оптимизировать его до совершенства и больше не выпендриваться.
Кто-то заставляет использовать именно сабж? Просто шлите нахер. А если не заставляют, есть вменяемые альтернативы.
> Правильно кто-то написал, что давно пора было сделать простой и понятный комментарий, отладить и оптимизировать его до совершенства и больше не выпендриваться.Поправил тебя, не благодари
раз фичи выходят значит кому-то это нужнопопробуй обобщить весь этот опыт, притом что он не перестает накапливаться и модифицироваться
и второе - самая проблемная часть
>>Правильно кто-то написал, что давно пора было сделать простой и понятный инструмент, отладить и оптимизировать его до совершенства и больше не выпендриваться.SVN
Простите.
Ага, очень понятный инструмент:
* Для развёртывания SVN-сервера почему-то нужна СУБД.
* Если нет связи с сервером, например в поездке - ничего не закоммитишь, ветку не сменишь.
* Ветка или тэг хранится как каталог файловой системы. То есть пространства каталогов, веток и тэгов не разделены. Как результат, нельзя с уверенностью сказать, то ли это ветка, то ли тэг, то ли просто каталог.
* Нет ни нормального мержа, ни ребейса.
Ваши абстрактные страхи я вполне понимаю - "не дай бог какой-то Васян вкорячит фичу, она-то будет работать, да отвалятся остальные". Но с другой стороны, DVCS - штука довольно сложная и ОБЯЗАНА развиваться. Собственно, для того и существуют "бета" версии - для обката фич.
Если сделать инструмент только на базовых фичах версионности, то в первую же неделю использования вы столкнётесь с массой отсутствующих маленьких, но очень приятных фич.
Надо пилить новую систему а-ля Hg, но без богомерзкого пестона - этим языком дубина-автор сразу же похоронил проект.
Совсем недавно узнал про ключ ---depth в git clone. Этож сколько времени и дискового пространства потрачено нами впустую...
А я вот сразу, когда мне понадобилось качать большую репу, ввел в Гугле "как скачать один коммит" и нашел про depth
> Совсем недавно узнал про ключ ---depth в git clone. Этож сколько времени
> и дискового пространства потрачено нами впустую...Теперь открой для себя --single-branch. Впустую или нет вопрос открытый, иногда надо откатить определённые коммиты, чтобы вообще собралось, или просто удалить неугодные изменения (но это путь вникуда, и не всегда разрабы желают кооперироваться).
> Добавлена поддержка системы непрерывной интеграции GitLab CI.Что это значит?
Добавили конфиги для запуска компиляции/сборки Гит внутри сабжа - https://github.com/git/git/commit/0e3b67e2aa25edb7e1a5c999c8...Кмк не та вещь, чтобы упомянуть. В т.ч. т.к. напрямую к Гиту отношения не имеет.
Какой же это комбайн.
Есть что то легковесное типа гита?
New folder -> Copy. Для 99% домашних проектов хватит, потом через вебморду выгрузишь на гитхаб если надо.
Fossil, но он неоднозначный.
Mercurial в целом можно использовать практически как drop-in замену svn, точно надёжнее гита.
> Fossil, но он неоднозначный.
> Mercurial в целом можно использовать практически как drop-in замену svn, точно надёжнее гита.Drop in замена всякого антиквариата нужна только всяким совсем необучаемым некромансерам, не способным в современные эффективные децентрализованные workflow.
Самое тут забавное - что индустрия как раз таки вернулась к классическому централизованному workflow с единой "точкой истины" в виде gitlab'a\github'a\bitbucket'а \ с развесистым CI\CD. На чуть более другом техническом уровне, да - но вожжи с колесами прям те же самые.
got (gameoftrees) есть
hg - понятнее, с гуём из коробки, децентрализованное - вообще самое то для новичков. но интеграция с ide начинает умирать, так же всё плохо с интеграциями в корпоративные порталы совместной разработки.
У Mercurial очень понятные команды, никогда не ощущал необходимости в GUI.
Особенно понятно иметь 3 типа веток, несколько голов в одной ветке и 2 типа обозначения коммитов
Но вот что меня потрясает - это такой комбайн, а ни одного бага, который бы портил данные, в целом не помню на своей практике чтобы гит имел хоть единый баг. Как они только так умело кодить умудряются?
"Просто пишите нормально" (c) - как раз тот случай когда так и сделали.
Некоторым код SVN нравился больше. Впрочем, как и UDP код против TCP под Лялих.
Гит стал сложнее матана. Уже есть вакансии git engineer?
Кто ж заставляет использовать что-то кроме pull, merge, add, commit и push?
Всё равно нужна отдельная вакансия про специалисту Git. Зарплата думаю 100 штук в месяц хватит.
С одной стороны почему бы и нет, зато можно устроиться в условный FAANG и работать левой пяткой, что-то за это получая.
С другой стороны в долгосрочной перспективе xз зачем это всё, учитывая развитие машинного обучения. Это всё можо будет автоматизировать и всех поувольнять.
В моей конторе в прошлом году появился prompt engineer, который составляет промпты для чатжпт. Всех джунов уволили. И что-то подсказывает, это только первые ласточки.
Когда поддержку systemd добавят?