libgit2 1.9.0 «Schwibbogen»

https://ru.wikipedia.org/wiki/Светильник-арка

Светильник-арка (свечная арка, подсвечник-арка, светильник-горка; нем. Schwibbogen) — традиционный рождественский светильник в виде свода арки, который обычно ставится на окно в дни адвента. Распространён в Северной Европе.

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

Арочная форма светильника символизирует небесный свод.

libgit2

Всегда было интересно, а куда дели libgit или libgit1?

А вообще крутая библиотека. Помню когда Microsoft только-только релизнул свою бесплатную MS Visual Studio Community 2013, я был удивлён что там операции с Git’ом как раз идут через эту библиотеку и всё работает очень быстро. И не требует ставить Git вообще.

Тогда как Qt Creator и даже вышедший позже CLion – как последние bash-лапшеписцы порождают вызовы system("git") с нужными параметрами и читают/затем парсят его stdout выхлоп, стыдобушка.

Нашёл даже свои сообщения 10-летней давности:

• Microsoft открывает исходные коды .NET, а также заявляет о кросплатформенности (включая GNU/Linux) (комментарий)
• https://imgur.com/8cTrDXL

Была бы консольная утилита на libgit2. А то «порт» git на windows - ужасное поделие

Прочитал сначала как «Swiborgen»

Тогда как Qt Creator и даже вышедший позже CLion – как последние bash-лапшеписцы порождают вызовы system(«git») с нужными параметрами и читают/затем парсят его stdout выхлоп, стыдобушка.

А libgit поддерживает все функции git'а?..

Всё равно, Theora'у не переплюнуть по кодовым именам (жаль, что версия 1.3 так и не вышла, а то там тоже был вариант как назвать ;) ).

Я думаю двойка в названии от версии самого Git.

MS Visual Studio Community 2013, я был удивлён что там операции с Git’ом как раз идут через эту библиотеку

Интересно, не было ли это одной из причин наконец-то запилить в свой бестолковый компилятор С99? Я как-то проверял конструкции из него, вплоть на компиляторе от 2015 студии работало.

С VS2017 майки тоже перешли от либгит к вызову бинарника

Архитектурно конечно не так красиво, но когда обычный libgit не умеел в ssh, тут уж не до красивостей

Schwibbogen

А можно кто-нибудь уже начнет говорить программистам, что пора как-то сворачивать этот затянувшийся идиотизм с «коднеймами» для каждого минорного чиха?

А можно кто-нибудь уже начнет говорить программистам, что пора как-то сворачивать этот затянувшийся идиотизм с «коднеймами» для каждого минорного чиха?

Шатлворту своему это сначала расскажите. ;-)

Да хоть кому. И да, дебунты забодали этим уже много, много лет назад.

Оно до сих пор использует libssh2 и поэтому не умеет автоматически парсить .ssh/config?

А эта реализация независима от самого git? Как обеспечивается совместимость?

А это точно минорный чих? Я вот на ЛОРе новостей про эту библиотеку раньше не видел, только косвенные обсуждения вроде того, которое по ссылке из второго комментария. И похоже, обновляется она не так часто.

В этом случае codename выглядит нормально.

Это точно (точно-точно) идиотизм, остальное не так важно.

Оно до сих пор использует libssh2

set(USE_SSH "Enables SSH support and optionally selects provider. One of ON, OFF, or a specific provider: libssh2 or exec. (Defaults to OFF.)")

Это так же бесполезно как и номер версии. У упомянутой бубунты по номеру хоть можно понять когда выпустили. А «1.9.0» или этот флюгегехаймен вообще ни о чем не говорит сходу. Так что можно и номера версий упразднить в пользу, например, sha коммита, это будет так же бесполезно, но хоть не придется решать как «назвать» релиз

А эта реализация независима от самого git?

Да.

Как обеспечивается совместимость?

Формат служебных файлов git документирован, так что в libgit2 независимая реализация. Хотя очень многие возможности git ещё не реализованы..

В этом случае codename выглядит нормально.

Кодовые имена в любом случае эталонное нинужно.

и читают/затем парсят его stdout выхлоп

Так же делает и консольный tig, в отличие от более быстрой gitui, использующей libgit2.
Но думаю, что скорость не связана с Rust. :)
Но возможно, когда-нибудь gitui будет использовать https://github.com/GitoxideLabs/gitoxide.

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

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

Что мне говорит номер «1.9.0» этой либы? Когда она вышла? Что было до этого, что добавили, что сломали, что пофиксили? Мне все равно надо идти в ченджлог чтоб все это узнать. Я могу разве что зная ту версию что сейчас у меня понять старее ли моя версия. Но при этом я даже не буду знать на сколько релизов она старее. А так как мне все равно надо смотреть в ченджлог то без разницы что используется в качестве номера версии.

Что мне говорит номер «1.9.0» этой либы? Когда она вышла? Что было до этого, что добавили, что сломали, что пофиксили?

А у упомянутой бубунты всё это входит в название?! 😱

то без разницы что используется в качестве номера версии

Есть разница для упрощения разрешения зависимостей.

Жджем 2.0 «Менора» :)

Это пилят левые чуваки или разработчики гита?

Это пилят левые чуваки

Да.

разработчики гита?

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

Что мне говорит номер «1.9.0» этой либы?

Он говорит тебе, что она новее чем 1.8.9 и что она старше, чем 1.9.4.

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

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

«Менора»

Непредсказуемо! :)

Были:

"Das Fliegende Klassenzimmer"
"Kleine Raupe Nimmersatt"
"Hubbeliges Krokodil"
"Stubentiger"
"Fisematenten"
"Zugunruhe"
"Absacker"
"Fernweh"
"Luftschloss"
"Torschlusspanik"

Соглашусь. Как они заколебали. Нужно вот было, к примеру, скачать пакет для Ubuntu 22.04 LTS, открываю их хвалёный LaunchPad и вижу:

https://launchpad.net/ubuntu/+source/gcc-arm-none-eabi

• The Plucky Puffin
• The Oracular Oriole
• The Noble Numbat
• The Jammy Jellyfish
• The Focal Fossa
• The Bionic Beaver
• The Xenial Xerus

Ну и какая из этих хреней относится к Ubuntu 22.04 LTS? Почему бы не использовать именно версии вместо этого идиотизма?

Или вот Google с их Android API Level заколебали. Почему я должен учить какие-то таблицы сопоставлений Android version == API Level № такой-то? Что мешало использовать версию Android для API?

Android 12	Level 32 
Android 12	Level 31

vs

Android 12	Level 12.2
Android 12	Level 12.1 

Эта хрень настолько заколебала Android-разрабов что они даже сайт сделали отдельный: https://apilevels.com/

но когда обычный libgit не умеел в ssh

https://libgit2.org/docs/guides/authentication/

Хм! У меня выхлоп git в stdout на русском. Как мегамозги из мелкософта с этим справятся?

З.Ы. Парсинг вывода - это крайняя мера, ИМХО.

Как мегамозги из мелкософта с этим справятся?

LC_ALL=C

Мне больше всех нравится пример giada. Оно ни разу у меня не проработало дольше минуты, не упав с сегфолтом, а иногда падало даже прямо сразу, зато на каждый релиз можно почитать сведения о сказочных персонажах.

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

А у упомянутой бубунты всё это входит в название?!

Как минимум «дата» релиза входит, что уже больше чем в номере версии 1.9.0

Есть разница для упрощения разрешения зависимостей.

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

Он говорит тебе, что она новее чем 1.8.9 и что она старше, чем 1.9.4.

И что мне дает эта информация. На сколько она новее, может там тупо какой-то польский перевод поправили, и мне это без разницы, а может вообще все переделали. Мое приложение может рассчитывать на какие-то особенности в этой либе, которые автор посчитал несущественными чтоб бампать мажор, а у меня все сломается, мне все равно надо смотреть ченджлог. А как обычному пользователю мне без разницы, я просто делаю apt upgrade и мне накатывает актуальную версию, или я открываю список релизов и если моя версия там не в самом верху то качаю актуальную.

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

Людям проще распарсить пару числе через точку чем хэш коммита и понять какая там раньше какая позже версия. Но если мне надо посмотреть список изменений хэш коммита будет проще, я могу сразу его использовать чтоб найти нужное место в логе. Так что для разных задач разные подходы. Если бы мои релизы назывались «однажды» -> «в студеную» -> «зимнюю» -> «пору» то люди тоже бы понимали порядок версий. В убунте аналогично, но опять же кроме как «раньше-позжее» это больше никакой информации не дает. А какой от этого смысл если все равно чтоб понять что менялось надо лезть в ченджлог \ репу, а там хэши коммитов будут удобнее?

И что мне дает эта информация.

То, чего не дает идентификатор коммита. Которого, кстати, может вообще не существовать.

Людям проще

А машинам? Можешь попробовать выкатить концепцию пакетного менеджера с управлением зависимостями, не использующего номера версий. Удобного, универсального. Прямо сюда, коротенько.

Это означает, что в версию 2.0 будут внесены изменения в API и ABI для поддержки SHA256, а также другие изменения, ломающие совместимость.
Основные изменения:
Несколько важных изменений, ломающих ABI.

хех мдауш

Я уж подумал, что они по канделябрам :)

Я не силен в немецком, но если верить переводчику, то Torschlusspanik und Fisematenten неплохо отражают происходящее :)

Можешь попробовать выкатить концепцию пакетного менеджера с управлением зависимостями, не использующего номера версий. Удобного, универсального. Прямо сюда, коротенько.

Важнее не то какая версия у пакета, а то какие «фичи» внутри. Если бы все писалось в парадигме «делает только одно дело и делает его хорошо» то это все не нужно было бы, мы бы говорили «apt install libgit2-commit_v1 libgit2-merge_v2 libgit2-log_v3». Но так как у нас все это запихано внутрь одной кодовой базы и развивается как такой «роллинг-релиз» это не взлетит просто так, нужно менять подход к написанию софта. Использовать что-то типа сабмодулей гита. При этом изменение интерфейса фичи должно вести к изменению ее «названия», а «номера версий» фич используются для отметок при рефакторинге и исправлении багов (и это не обязательно монотонно изменяющиеся число, можно что угодно использовать лишь бы позволяло понять то же самое у тебя сейчас установлено или нет). Тогда бы мы могли брать пакеты с тем набором фич, который нам нужен, обновляли бы только то что нужно, могли бы всегда брать последние версии зная что обратная совместимость гарантирована и меньше бы конфликтов зависимостей было бы. То, как разработка ведется сейчас, такой подход не поддерживает, исключение разве что веб с версионированием API.

А, ну и пакетный менеджер соответственно не просто версию пакета бы сравнивал а смотрел что внутри. Условно такой requirements.txt из питона, только представляем что это у нас не проект с кучей либ в зависимостях а пакет с кучей фич в «зависимостях»

И вот ты все равно оставил инкрементные номера версий для обозначения патчсета, как минимум.

и это не обязательно монотонно изменяющиеся число, можно что угодно использовать

Ага. А раз у нас все равно есть номера, то можно использовать их.

А раз у нас все равно есть номера, то можно использовать их.

Можно, но не обязательно. Нужно что-то для того чтоб понять установлена ли у тебя последняя версия или нужно обновить. Можно использовать номера, эмодзи, названия этих икеевских фьордов, да хоть таймзону или md5. Если у нас гарантирована обратная совместимость (договоренностью о том что интерфейс в рамках одного «имени» фичи не меняется) то мы в целом всегда можем обновляться до последней имеющейся версии не боясь что что-то сломается. А больше ни для чего (для пользователя пакета) эти идентификаторы нужны и не будут.

И вот ты все равно оставил инкрементные номера версий для обозначения патчсета, как минимум.

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

Вообще изначально то было «названия релизов не нужны» - «так и номера тоже ничего полезного не дают». Я бы хотел отслеживать не номер релиза пакета, а состав пакета. Что будет использоваться для идентификации компонентов особого значения не имеет. Вот как в БД - есть таблица с именами юзеров, колонки name и id. Идентификатор записи должен быть уникальный, но он в целом остается под капотом, пользователь видит «человеческое» значение - name. Так и тут - внутри конечно какие-то идентификаторы будут, но пакет будет «описываться» не каким-то абстрактным числом, или названием релиза, которые о составе пакета ничего не говорят, а набором важных для пользователя «артефактов».

Ну я поэтому и написал в прошедшем, сейчас то может уже и умеет))