LINUX.ORG.RU

Git 2.55

 , , , ,

Git 2.55

0

3

Представлен релиз распределенной системы управления исходными текстами Git 2.55. Среди ключевых изменений: включение по умолчанию сборки с Rust, реализация для Linux процесса fsmonitor, новая стратегия переупаковки инкрементального MIDX-индекса, команда git history fixup для исправления коммита, оптимизация генерации битовых карт доступности объектов, поддержка параллельного выполнения хуков, команда git format-rev. Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию принято 505 изменений, подготовленных при участии 100 разработчиков, 33 из которых впервые приняли участие в разработке Git.

Основные новшества (github.blog, gitlab.com/blog, gitlab.com/git-scm):

  • По умолчанию включена поддержка компонентов на языке Rust. Компилятор rustc добавлен в число сборочных зависимостей. Для сборки без Rust можно использовать флаг NO_RUST=1 при запуске утилиты make или -Drust=disabled при выполнении meson configure. Возможность отключения сборки с Rust будет поддерживаться до ветки Git 3.0, в которой Rust будет включён в число обязательных зависимостей. На языке Rust реализована прослойка для переносимости между конфигурациями с хэшами SHA-1 и SHA-256, а также некоторые внутренние функции, такие как кодирование и декодирование целочисленных значений переменной длины. В будущем ожидается переработка на Rust более значительны внутренних компонентов Git.
  • В экспериментальную команду "git history", предоставляющую возможности для перезаписи истории изменений, добавлена операция «git history fixup» для исправления коммита. Операция fixup позволяет перенести изменения, добавленные через git add, в более ранний коммит и автоматически переписать все последующие коммиты по аналогии с выполнением команды git commit --fixup=<commit> и запуска git rebase --autosquash <commit>~.
  • Для платформы Linux реализован фоновый процесс fsmonitor, отслеживающий изменения в файловой системе при помощи механизма inotify и позволяющий обойтись без перебора всего рабочего каталога при выполнении таких команд, как git status. Включение осуществляется через настройку «core.fsmonitor».
  • В команду git repack добавлен режим --write-midx=incremental, реализующий новую стратегию обновления метаданных в инкрементальном MIDX-индексе (multi-pack index), позволяющую обойтись без переупаковки всего индекса. В инкрементальном многопакетном индексе вместо одного большого индекса, содержащего информацию о распределении объектов по pack-файлам, применяется разделение на слои — каждый слой охватывает определённое число pack-файлов и хранится в отдельном bitmap-файле. Подобная структура позволяет добавлять в индекс данные об объектах в новых pack-файлах, прикрепляя к индексу новые слои без перестроения уже имеющихся слоёв.Команда git repack --write-midx=incremental позволяет добавить в инкрементальный MIDX-индекс новый слой, охватывающий недавно созданные pack-файлы. В сочетании с режимом упаковки репозиториев --geometric новая команда даёт возможность объединить новые объекты из нескольких pack-файлов в один более крупный pack-файл и при необходимости осуществить упаковку и слияние нескольких соседних слоёв инкрементального MIDX-индекса. Подобная стратегия позволяет при выполнении git repack переписывать только верхние слои, оставляя старые большие слои нетронутыми, а также исключить неконтролируемое разрастание цепочки слоёв, поддерживая общее число слоёв на уровне, пропорциональном логарифму от общего числа объектов.
  • Значительно оптимизирована генерация битовых карт доступности объектов за счёт нового алгоритма обхода дерева объектов, исключающего лишнюю рекурсию, кэширования позиций объектов, сортировки битовых карт до их объединения операцией XOR и переработки кода для создания битовых карт псевдослияния (pseudo-merge). В тестовом репозитории оптимизации позволили сократить время генерации битовых карт с 612 до 294 секунд.
  • Реализована возможность параллельного выполнения независимых хуков в файлах конфигурации. Параллельно не могут запускаться хуки, влияющие на совместное состояние или учитывающие его, например, меняющие примечания к коммитам или инспектирующие индексы и рабочее дерево. При этом можно параллельно запускать хуки для проверки линтером и выполнения unit-тестирования. Допускающие параллельное выполнение хуки настраиваются через параметр hook.имя_хука.parallel = true. Число одновременно запускаемых работ определяется через настройку hook.jobs, hook.<event>.jobs или опцию командной строки -j.
  • В команде git pack-objects --path-walk реализована возможность указания фильтров, таких как blob:none, blob:limit=<n>, tree:0, object:type=<type>, sparse:<oid> и combine:. В проведённом тесте отбрасывание блобов при выполнении --path-walk позволило на 16% сократить размер сформированного pack-файла.
  • Добавлена команда git format-rev для форматирования ревизий и имён объектов, упоминаемых в списках коммитов или встречающихся в произвольном тексте (например, можно использовать в хуках для обработки примечаний к коммитам).
       git last-modified | git format-rev --stdin-mode=text --format=%an
     
       Junio C Hamano	builtin/commit.c
  • Включено по умолчанию экранирование большинства последовательностей управления терминалом в информационных сообщениях и тексте ошибок, передаваемых сервером. При обращении к вредоносному серверу подобные escape-последовательности могли использоваться для скрытия или модификации вывода, например, через escape-последовательности для перемещения курсора и очистки текста. Оставлена поддержка escape-последовательностей для выделения элементов цветом.
  • Команда git checkout -m теперь автоматически сохраняет конфликтующие локальные изменения в stash-области без необходимости незамедлительно разрешать конфликт.
  • В команду git push добавлена возможность помещения ветки на несколько внешних Git-серверов одной командой. Например, для передачи ветки main не только на основной сервер, но и на зеркала можно создать группу publish из серверов github, gitlab и mirror:
git config remotes.publish "github gitlab mirror" 
git push publish main
  • В команду git log --graph добавлена опция --graph-lane-limit=<N> для ограничения числа вертикальных полос при визуализации веток, что позволяет оставить место на экране под данные о коммитах в репозиториях с большим числом веток.
...
\* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\\ \\ \\ \\ \\
| \* | | | ~ cf48887610 compat/posix.h: simplify GIT\_GNUC\_PREREQ() comparison
| \* | | | ~ ffd45926dc compat/posix.h: clean up GIT\_GNUC\_PREREQ() and UNUSED
|\\ \\ \\ \\ \\~
| \* | | | ~ 3f5203eeb4 ls-files: filter pathspec before lstat
  • В команды git log и git rev-list добавлена опция --max-count-oldest=<N>, позволяющая выбрать N самых старых коммитов в диапазоне.

>>> Источник: OpenNET

★★★★★

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

поддержка компонентов на языке Rust

$ tokei --compact:

LanguageFilesLinesCodeCommentsBlanks
C6393925093009004139450215
C Header3434609522201175866308
Rust111666137666224
dataman ★★★★★
() автор топика
Ответ на: комментарий от dataman

выглядит, будто его специально туда добавили лишь бы людей побесить и только для этого

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

Тем более, что уже есть

gitoxide is an implementation of git written in Rust for developing future-proof applications which strive for correctness and performance while providing a pleasant and unsurprising developer experience.

Вот там бы и сконцентрировались все вместе.

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

его специально туда добавили лишь бы людей побесить и только для этого

Ну так-то вполне валидная причина - FOSS это же «just for fun» ;-)

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

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

К следующему релизу должны переписать с C на rust все Comments и Blanks - что составит почти 25% всего легаси кода. Это даст огромные преимущества в безопасности и производительности, в первую очередь благодаря строгому компилятору и системе владения (ownership) памяти.

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

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

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

У Git’а разве с этим были большие проблемы?..

А надо обязательно ждать проблем?

zabbal ★★★☆☆
()

А ведь уже прошло больше 20 лет, этот проект как react os, все не может быть допилен , до какой-то контрольной точки)

REDDERa
()
Ответ на: комментарий от scanner

Кто сует? Поменьше надо луддитам истеричкам на лорчиках верить. В реальности как только находят время и силы опробывать и сравнить говорят дайте два и какого хрена лет, хотя бы, 20 назад что такое не запилили. Сишка просто выбрасывается в мусорку, на свое заслуженное место, плюсы дипрекейтятся и берутся на поруки растовой частью приложения.

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

Чем этот Rust так хорош, что его везде суют?

Тем же чем и плох, из-за чего все плюются – «боровом» (‘borrow checker’).

Боров это новая концепция управления памятью, которая отличается как от ручного управления, как в C, так и от автоматического управления, как Jav’е или Python’е. Боров требует много возни, но за то даёт очень сильные гарантии.

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

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

Весь сколько-нибудь значимый foss давно уже контролируется корпорациями

eagleivg ★★★★★
()
Ответ на: комментарий от shkolnick-kun

там не было коммитов с апреля.

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

В команду git repack добавлен режим –write-midx=incremental, реализующий новую стратегию обновления метаданных в инкрементальном MIDX-индексе (multi-pack index), позволяющую обойтись без переупаковки всего индекса

Значительно оптимизирована генерация битовых карт доступности объектов за счёт нового алгоритма обхода дерева объектов

и т.п. В своей основе это ж очень простой проект. Вон в libgit2 уже запилен экзешник, позволяющий делать базовые операции.

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

кто это потом поддерживать будет?

Поддерживать? Хахахахаха! XXI век на дворе, искусственный интелект превосходит естественный, нейросеть в каждом утюге… Напишут новое, ни с чем не совместимое!

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

Код и комменты считаются в токенах? (%

Да. Потраченных на нейронку.

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

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

Кому надо? Школоте - они всё-равно пользоваться будут только до тех пор пока мамка не загонит уроки делать. Форумным обиженцам - им даже с помощью ИИ такое не осилить. Разработчикам - они уже свой выбор сделали.

Всё эти хейтерские «надо» как обычно упираются в отсутствие в маня-мирке ресурсов и аудитории.

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

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

нет связи

rsync ★★
()

Думаю, стоит всё же пояснить причину негативного восприятия внедрения rust в git, ядро и прочее.
Для кого-то это действительно просто хейтерство и объективной разницы на чём оно написано нет, ведь они не будут читать и редактировать код git, не будут собирать его - какая разница, на чём он там написан - это ведь просто бинарный пакет, да и в случае rust безопаснее вроде.
С другой же стороны подобные изменения в разы усложняют сложность сопровождения пакетов, дистрибутивов, да и вообще системы.
На source-based дистрибутивов помимо того, что нужно обеспечивать инструментарий для всех используемых в пакете языков (а в случае rust это огромная говнина в виде llvm и его зависимостей), но иногда и приходится вмешиваться в процесс сборки и править исходники, когда что-то не собирается. И когда в системе появляется ещё один язык, при этом молодой язык и не очень стабильный в плане фич и нововвведений, это очень сильно увеличивает нагрузку на сопровождение системы - если не реальную, то как минимум психологическую. Наличие в языке своего экосистемного пакетного менеджера только усугубляет ситуацию.
В общем, какой быт хороший и безопасный язык не был, но в текущем виде он усложняет поддержку системы и увеличивает техдолг. Особенно это конечно будет ощущаться если поддерживать свой дистрибутив.
Конечно крупные дистрибутивы вроде федор и дебианов раст не сильно напрягает - ведь все, кому он не нравился - ушли из его команды, а остальным за это ещё и деньги наверняка доплачивают - но ведь это как раз то, что нужно корпорациям - контроллировать крупные дистрибутивы полностью. Им не нужно, чтобы какие-нибудь 3.5 калеки могли сделать свой дистрибутив или ОС и поддерживать её в актуальном виде, иначе они просто станут никому не нужны

mittorn ★★★★★
()

Гит только для ядра нужен, а так - не нужен.

x-signal ★★
()
Ответ на: комментарий от zabbal

Форумным обиженцам - им даже с помощью ИИ такое не осилить

не проецируй на других свою бездарность, лол. «даже с помощью ИИ»))

Разработчикам - они уже свой выбор сделали.

да-да, я помню как ты так же балаболил про дыбас в сустемд. Потом пришел Леня Потный и начал туда впиливать варлинк. И оказалось что это не «разработчики», а просто овцы.

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

лол. «даже с помощью ИИ»))

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

начал туда впиливать варлинк

И? Поскольку запилить нормальный IPC в ядро не дала фимозность Линуса - пришлось искать обходные пути. Или ты опять до усрачки испугался очередной новой технологии? Ну подотри подливу и ещё поплачь про своё неосиляторство.

это не «разработчики», а просто овцы

не проецируй на других свою бездарность

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

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

Поскольку запилить нормальный IPC в ядро не дала фимозность Линуса - пришлось искать обходные пути

в андрйде давно запилили биндер - сколько же там было проблем с нехваткой памяти vmalloc из-за утечек в нём. В итоге вроде починили, но на это ушло 10 лет усилий ЦЕЛОГО ГУГЛА, а ты хочешь чтобы силой одного лишь потного это сделали? Но вообще есть shm, есть сокеты, есть футексы - считай, всё что нужно для ipc есть и так в юзерапи, возможно конечно не такое удобное

кудахтать

тут только один человек кудахтает, с ником zabbal

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

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

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

потратил времени столко же, сколько самому писать

То есть, старое доброе правило «Хочешь сделать хорошо - сделай сам!» всё ещё верно?.. ;))

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

Rust заставляет пользователя постоянно думать над вопросом управления памятью, каким способом это связано с безопасностью?

Вот именно, что никаким.

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

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

То есть по существу - касательно переписывания комментов и пустых строк - возражений нет? Технические вопросы можно обсудить в рабочем порядке.

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

Rust заставляет пользователя постоянно думать

Бедолага, тяжело с непривычки?

каким способом это связано с безопасностью?

Прямым - в Rust в принципе невозможны целые классы атак. Именно поэтому всё большее количество старья будет заменено безопасным кодом в ближайшей перспективе.

То что неосиляторы при этом будут хныкать и смешно сучить ножками - просто дополнительный приятный бонус.

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

То что неосиляторы

именно неосиляторы создать пару new-delete/malloc-free и идут в язык, где им компилятор будет в каждой (в каждой!) строке напоминать про управление памятью

rsync ★★
()

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

Пропал Калабуховский дом.

thunar ★★★★★
()

Ты будешь когда-нибудь выкладывать темы интересные всем, а не только упоротым программерам, которые даже ОСь не могут установить?

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

именно неосиляторы создать пару new-delete/malloc-free и идут в язык, где им компилятор будет в каждой (в каждой!) строке напоминать про управление памятью

неосиляторы - осиляторы - суперосиляторы

Забавный код от меня, суперосилятора:

using MaxHash = char[256];

MaxHash * h = new MaxHash;
...
delete h; // MSVC happy
delete [] h; // g++ happy
--
MaxHash * h = new MaxHash[1]; 
delete [] h; // вариант который устраивает всех
sarumeister
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.