LINUX.ORG.RU

Git 2.48

 , ,

Git 2.48

0

2

Состоялся выпуск 2.48 распределенной системы управления версиями Git, написанной на языке C и распространяемой по лицензии GNU GPL 2.

Список основных изменений:

  • Новая переменная конфигурации remote.<name>.serverOption оказывает такое же действие, как если бы опция --serverOption=<value> была задана из командной строки.
  • Команда git rebase --rebase-merges теперь использует имена ветвей в качестве меток, когда это возможно.
  • Команды git notes add и git notes append с новым флагом -e открывают заметки в $GIT_EDITOR перед сохранением.
  • Улучшена документация git bundle об использовании --all при создании пакетов.
  • Удалена поддержка старых версий libcURL и Perl.
  • Улучшена работа git mergetool при возникновении ошибки команды.
  • Команды git bundle --unbundle и git clone, выполненные для файла пакета, запускают fsck для новых объектов с настраиваемыми уровнями проверки fck.
  • Если при выполнении git fetch $remote обнаруживается, что отсутствует refs/remotes/$remote/HEAD и на какую ветку указывает другая сторона своим HEAD, refs/remotes/$remote/HEAD обновляется, чтобы указывать на неё.
  • Теперь git fetch учитывает настройки remote.<remote>.followRemoteHEAD для отслеживания HEAD в refs/remotes/<remote>/HEAD.
  • В git range-diff добавлена поддержка опции --diff-merges для сравнения коммитов слияния в сравниваемых диапазонах.
  • Улучшена подсистема reftable.
  • Добавлена поддержка компиляции с более производительными реализациями алгоритма SHA-1 вместо используемого сейчас алгоритма SHA1DC с детектированием коллизий ($ make OPENSSL_SHA1_UNSAFE=1 или $ make BLK_SHA1_UNSAFE=1).
  • Улучшена совместимость cо стандартом C23 и GCC 15.
  • Проведена оптимизация git describe.
  • Добавлена возможность компиляции системой сборки Meson.
  • Другие улучшения и исправления ошибок.

>>> Основные изменения в блоге GitHub

>>> Полный список изменений версии 2.48 на GitHub

★★★★★

Проверено: hobbit ()
Последнее исправление: dataman (всего исправлений: 7)

Добавлена возможность компиляции системой сборки Meson

причем я так понял ее хотят сделать основной. Сейчас основная система сборки - это Makefile на 4к строк.

Плюс в contrib еще есть CMakeLists.txt с каким-то невероятным говнокодом, который надо сжечь и закопать - так на цмаке не пишут

Lrrr ★★★★★
()

Всё допиливают и допиливают фичи. Тем временем 99% пользователей: init, clone, status, log, diff, pull, add, commit, push и всё.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Всё допиливают и допиливают фичи. Тем временем 99% пользователей: init, clone, status, log, diff, pull, add, commit, push и всё.

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

А 99% пользователей будут это читать?

Pro Git вообще-то уже написан и даже на русский переведен.

vitus
()
Ответ на: комментарий от Lrrr

Плюс в contrib еще есть CMakeLists.txt с каким-то невероятным говнокодом, который надо сжечь и закопать - так на цмаке не пишут

А на CMake как не пиши, получается невероятный говнокод, потому что убогонький и абсолютно невыразительный недо-DSL вставляет палки в колеса на очевидных действиях.

причем я так понял ее хотят сделать основной

И это хорошо. Не CMake-портянки занюхивать же. Чем больше крупных репозиториев перейдут на Meson – тем скорее autotools нового поколения, этот позор экосистемы C и C++ под названием CMake отправится на свалку истории, где ему самое место. Уж C- и C++-разработчики могли сделать себе адекватную систему сборки, но родили CMake. Как такое получилось вопрос хороший.

EXL ★★★★★
()
Ответ на: комментарий от pihter

А если звезды не зажигают - значит это никому и не нужно)

pihter ★★★★★
()
Ответ на: комментарий от EXL

Чем больше крупных репозиториев перейдут на Meson

Не лишним будет напомнить о https://muon.build. У него, конечно, нет всех возможностей Meson, и очень многие meson-проекты им не собираются, но зато он на Сишечке. :)

dataman ★★★★★
() автор топика
Ответ на: комментарий от guyvernk

Сеньёры коммитят сразу в мастер.

ox55ff ★★★★★
()
Ответ на: комментарий от EXL

убогонький и абсолютно невыразительный недо-DSL

ну и что там убогого? В мезоне гораздо меньше фич, его единственное преимущество - это меньший размер бинарника и более легкая процедура бутстрапа (в случае с muon). Если ты не читаешь документацию цмаке, пытаешься сделать по-своему и огребаешь из-за этого баги - то это только твои проблемы.

Конкретно в случае git в цмаке парсят тот самый Makefile на 4к строк, определяют наличие хедеров компиляцией тестовых программ, и т.п.

Lrrr ★★★★★
()
Ответ на: комментарий от ox55ff

Тем временем 99% пользователей: init, clone, status, log, diff, pull, add, commit, push и всё.

Даже rebase нет, видимо совсем нубы какие-то.

annulen ★★★★★
()
Ответ на: комментарий от X-Pilot

merge лучше, чем rebase

Тёплое лучше, чем мягкое

annulen ★★★★★
()
Ответ на: комментарий от ox55ff

я вот перешел на git switch вместо git checkout, активно пользуюсь git restore и git worktree.

Еще там с относительно недавних пор можно подписывать коммиты ssh-ключами.

Так что нет, в гите появляется очень много полезных фич, и кто про них не читает - тот ССЗБ.

Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

worktree вообще древняя фича, только раньше это был скрипт в контрибе

annulen ★★★★★
()
Ответ на: комментарий от X-Pilot

merge как раз портит историю merge-коммитами, в отличие от rebase.

Основное правило - если с твоей веткой не работает никто кроме тебя, делай rebase. Если работает, то там уже выбора нет, только merge.

Lrrr ★★★★★
()
Ответ на: комментарий от EXL

Уж C- и C++-разработчики могли сделать себе адекватную систему сборки, но родили CMake

А точно могли? Я вот не уверен. Вся история C и - в особенности! - C++ заключается в создании монструозного говна.

hateyoufeel ★★★★★
()
Ответ на: комментарий от ox55ff

Всё допиливают и допиливают фичи. Тем временем 99% пользователей: init, clone, status, log, diff, pull, add, commit, push и всё.

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

MoldAndLimeHoney
()
Ответ на: комментарий от EXL

И это хорошо. Не CMake-портянки занюхивать же. Чем больше крупных репозиториев перейдут на Meson – тем скорее autotools нового поколения, этот позор экосистемы C и C++ под названием CMake отправится на свалку истории

На счёт Autotools соглашусь, а вот на счёт Meson... Ну не знаю, я уж лучше на qbs перейду чем на Meson, собственно от части я так и сделал.

У Meson не сильно то лучше синтаксис, там где на CMake можно написать относительно лаконичный скрипт, то у Meson - это будет длинная портянка. К примеру они ведь так и не завезли регулярки для поиска файлов, а вместо этого предлагают написать внешний «*.sh» 🤦. Многих функций, которые есть в CMake и других системах сборки, там попусту нет, либо предлагают делать костыль на подобии того, что выше. Нормальных команд управления тоже нет. Безкостыльность? Лаконичность? Автоматизация? Где всё это?

Dr64h ★★★
()
Ответ на: комментарий от annulen

rebase не нужен. merge делается в веб-интерфейсе gitlab’а.

ox55ff ★★★★★
()
Ответ на: комментарий от Dr64h

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

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

Lrrr ★★★★★
()

Опять про русофобское ПО на лоре пишут? Сколько можно!

Aber ★★★★★
()
Ответ на: комментарий от Lrrr

merge как раз портит историю merge-коммитами, в отличие от rebase.

merge-коммиты ничего не портят: остается информация что было до, что было после, какие изменения были во время merge'а (если нужно было разрешать конфликт). И да, мне важнее целостность истории, чем ее «линейность».

X-Pilot ★★★★★
()
Ответ на: комментарий от sena

Meson - это какой-то враппер над ninja-build [но на Python]?..

X-Pilot ★★★★★
()
Ответ на: комментарий от Lrrr

я вот перешел на git switch вместо git checkout

Полез смотреть, что за switch, а там написано:

THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.

Как-то боязно стало. Хотя по описанию штука прикольная.

Beewek ★★★
()
Ответ на: комментарий от X-Pilot

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

И да, мне важнее целостность истории, чем ее «линейность».

ребейз не нарушает целостность истории.

Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

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

Вы когда-нибудь занимались поиском регрессий с помощью git-bisect (=на каком из коммитов код сломался)?

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

X-Pilot ★★★★★
()
Ответ на: комментарий от X-Pilot

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

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

Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

ну и что там убогого?

Сконструировать более убогонький DSL, чем тот который высрали наркоманы из Kitware это надо уметь. Не зря главный сборочный файлик имеет расширение .txt, потому что им видимо было стыдно дать какое-то осознанное название этому позорищу. Там сделано паршиво всё.

CMake DSL собрал буквально все недостатки самой разной скриптоты, начиная от виндовой регистронезависимости которая превращает любую кодовую базу в помойку (постоянно встречаю IF(), If(), if() даже внутри одного CMakeLists.txt) и заканчивая подобными приколами с функциями и неопределёнными переменными: За что так не любят cmake? (комментарий)

А самой говнявой вишенкой в бочке CMake’ового дерьма являются не только кривые полуработающие FindModules которыми засран весь GitHub, а ещё и вот эти убогие костыли и подпорки, которыми обрастает любой крупный проект: https://github.com/raysan5/raylib/tree/master/cmake

От сборочной системы в 2025 году ожидаешь базовой функциональности вроде function(join_paths и macro(enum_option из коробки. Но вместо этого разработчики должны писать тот убогий хлам что по ссылке выше и засирать им свои репозитории, постоянно чиня и проверяя не рассыпалась ли эта убогая CMake-лапша при изменении версии.

cmake (written in C++) - so huge and bloated, compilation takes longer than compiling GCC (!). It’s not even possible to create freestanding Makefiles, since the generated Makefiles call back into the cmake binary itself. Usage of cmake requires learning a new custom scripting language with very limited expressiveness. Its major selling point is the existence of a clicky-click GUI for windows users.

https://suckless.org/sucks/

Ах да, CMake ведь кстати клал хер на переносимые Makefile’ы, у него они вызывают сам cmake из себя. Тогда вдвойне непонятно почему они не смогли родить нормальный DSL, который бы имел:

  • Кучу удобных и лаконичных конструкций частоиспользуемых в системе сборки вещей по типу заменить строку в файле, вызвать внешнюю утилиту, перебрать что-то в цикле.
  • Удобные dict/list/tuple и пр. примитивы которыми CMake до сих пор не обзавёлся и разработчики серьёзных библиотек вынуждены срать себе в каталоги cmake кривоработающими велосипедами.
  • Адекватный Pattern Matching, который много где пригодился бы в сборочных скриптах, делая их лаконичными. Уж в 2025’ом то!

Когда разработчики наедаются CMake-лапши (как я в своё время) у них возникает закономерный вопрос: блджд, я тут свой софт пишу или борюсь со сборочной системой и порождаю криво-косые CMake-велосипеды из-за его ограниченности и наркомании?! И именно тогда встаёт вопрос о переходе на другие системы сборки.

Так что Git, X.Org, Wayland, GLib, GTK+, QEMU, systemd, проекты GNOME всё правильно делают что посылают виндузотных наркоманов KitWare с их очередным кривым autotools’ом.

Смерть CMake только оздоровит C, C++ экосистемы.

EXL ★★★★★
()
Ответ на: комментарий от dataman

Нафиг нужен этот мюон? Ладно бы что то свое пилить, но воспроизводить старые версии мезона - это ж эталонное ненужно?

anonmyous ★★
()
Ответ на: комментарий от EXL

Сконструировать более убогонький DSL, чем тот который высрали наркоманы из Kitware это надо уметь

оценочные суждения

А самой говнявой вишенкой в бочке CMake’ового дерьма являются не только кривые полуработающие FindModules которыми засран весь GitHub

cmake давно рекомендует использовать config mode

От сборочной системы в 2025 году ожидаешь базовой функциональности вроде function(join_paths

cmake_path(APPEND ...).

и macro(enum_option из коробки

https://github.com/search?q=repo%3Araysan5%2Fraylib+enum_option&type=code городить макрос, чтобы не писать 2 лишних строчки в двух местах - говнокод.

if (NOT «;${${var}_VALUES};» MATCHES «;${${var}};»)

говнокод в говнокоде

https://suckless.org/sucks/

оценочные суждения от клоунов, софтом которых вряд ли пользуется кто-то кроме них самих

Ах да, CMake ведь кстати клал хер на переносимые Makefile’ы

трудно не положить хер на то, чего не существует в природе

Удобные dict/list/tuple и пр. примитивы которыми CMake до сих пор не обзавёлся

https://cmake.org/cmake/help/latest/command/list.html ???

Так что Git, X.Org, Wayland, GLib, GTK+, QEMU, systemd, проекты GNOME всё правильно делают что посылают виндузотных наркоманов KitWare с их очередным кривым autotools’ом

https://github.com/mesonbuild/meson/blob/6b99eeb2c99d4af4be2562b25507541bfd842692/mesonbuild/modules/gnome.py

очевидно что в cmake гномерам просто не позволили нафигачить в исходники эту кучу говнокода. А в meson - позволили, вот они и носятся с ним.

остальные оценочные суждения я поскипал, лень. По итогу все как я и говорил - ты не читал доку, навалил кучу говнокода, и пытаешься выдавать проблемы с легаси за проблемы cmake. В то время как у meson легаси пока просто нет, но когда появится - удачи помейнтейнить вон тот скриптик повыше.

Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

А почему кто то должен с моей веткой работать?

Что за дебил-бейсед-девелопмент?

guyvernk
()
Ответ на: комментарий от Lrrr

В то время как у meson легаси пока просто нет, но когда появится - удачи помейнтейнить вон тот скриптик повыше.

А в чём проблема? Там же Python, который:

  • Типизируется хинтами, имеет кучу валидаторов, линтеров, форматтеров, и пр. батареек.
  • Имеет относительно нормальный человекочитаемый синтаксис вместо CMake-ссанины.
  • Python для скриптования сегодня знают все и поддерживают все IDE, он используется как язык скриптования в куче инструментов.
  • Куча средств для рефакторинга и мейнтейнинга.

Если представить этот скрипт на CMake DSL.. Впрочем такое лучше не представлять. Ибо получится адище примерно такое же что стыдливо запихнули в contib у Git’а. И оно уж точно поддерживаться будет куда как сложнее.

Если у меня какая-то сильно замороченная сборка которую нужно очень гибко конфигурировать то Meson как в этом примере с GNOME даёт мне всю мощь и богатство Python’а. А что даёт CMake? Убогую нечитаемую дрисню которая валяется в cmake директориях всяких крупных проектов?

навалил кучу говнокода

Именно так. Кучи CMake-говнокода обитают в директориях cmake любых проектов, которые имели неосторожность перейти на эту систему сборки. Особенно такое забавляет:

Спрашивается, а нахрена вы ребята с CMake-то страдаете, если вынуждены из него же вызывать лаконичные написанные вами Python-скрипты, потому что ваша CMake-лапша получилось ограниченной и не могущей в нужные вам вещи?! Нахрена нужен этот садомазохизм для C/C++ разработчиков? У них что нет дел важнее, чем ковыряться с CMake-лапшой, а потом дёргать из неё питухонца?

ты не читал доку

Кстати документация у CMake одна из самых отвратнейших в мире СПО. Абсолютное отсутствие примеров и тонны невнятной воды. Счастье если ты именно в документации нашёл решение своей проблемы, а не в Google.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 3)
Ответ на: комментарий от EXL

В то время как у meson легаси пока просто нет, но когда появится - удачи помейнтейнить вон тот скриптик повыше.

А в чём проблема? Там же Python, который:

Не-не-не Дэвид Блейн, идите вы подальше со своей уличной магией… ;)

Хуже может быть только сборочная система на C++. Видел я и такие предложения…

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

если вынуждены из него же вызывать лаконичные написанные вами Python-скрипты

Пусть лучше так, чем встраивать интерпретатор питона в сборочную систему…

sena ★★
()
Последнее исправление: sena (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.