libgit2 1.9.3

Весьма печально, что git не зависит от libgit2:

• code duplication;
• потенциальные data corruption из-за рассогласованного поведения в будущем.

Будет печально, если перейдут на Gitoxide, когда her/him допилят.

«git зависящий от libgit2» это утилита lg2.

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

code duplication;

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

Меньше шансов на рваться на ситуацию, что была с zip-архивами.

А можно для тех кто в танке объяснить что сабж не может, в отличие от "эталонной" реализации в git? В каких сценариях libgit2 окажется "не готовой"?

А то я посматриваю на got (проект ребят из OpenBSD), и… вот оно ничего толком не может. Я его тыкал довольно давно, но и git не стоит на месте.

В каких сценариях libgit2 окажется «не готовой»?

Вангую, что в сценарии «заменить git внутри GitHub». Потому что иначе MS не вкладывали бы бабки в официальную реализацию)

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

Как минимум, есть ещё jgit, через который работают все проекты на Java

Ну превратили бы стороннюю библиотеку в референсную. Или лучше выделили бы референсную библиотеку из референсной реализации. Логика «две рассогласованные реализации это хорошо» выше моего постижения.

Или лучше выделили бы референсную библиотеку из референсной реализации

Над этим работают. Там код, изначально рассчитанный на использование в консольных утилитах, который может в любом момент сделать abort(), и переделать его в библиотечный не так просто.

в основном проекте git команды делятся на 2 независимых множества, высокоуровневые (plumbing) и низкоуровневые (porcelain). Это сделано как раз для того, чтобы любое из этих подмножеств можно было подменить на альтернативную реализацию.

В целом, в git давно суют много нужного только корпоратам с большими монорепами гуано, повышая сложность проекта. Сейчас еще и на раст хотят переписывать. Хотя в основе своей git очень прост и логичен.

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

Авторы официального гита никаких «двух реализаций» не делали. Они пишут свой гит и только его. Вопросы «зачем нам вторая» надо задавать авторам libgit2 и прочих гит-библиотек.

иначе MS не вкладывали бы бабки в официальную реализацию

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

Вангую, что в сценарии «заменить git внутри GitHub». Потому что иначе MS не вкладывали бы бабки в официальную реализацию)

У МС аллергия на сишечку и хороший код, так что такие мыслепреступления никогда не взлетят.

У МС аллергия на сишечку и хороший код, так что такие мыслепреступления никогда не взлетят.

Что не взлетит? Сотрудники МС давно работают над git

Так основной git уже давно начал мигрировать в раст!

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

Если бы libgit2 был достаточно хорош для МС, то они только в него и форсили бы нужные им фичи, так как официальный git не создавался для работы в Windows и архитектурно плохо подходит для этой ОС. Как и для интеграции с IDE, и всего остального, что нужно корпоратам.

со специальным исключением для линковки, позволяющим не раскрывать исходный код

Интересно, это совместимо с использованием в BSDL-коде?

Если бы libgit2 был достаточно хорош для МС

libgit2 подстраивается под git, поэтомму форсить в него свои фичи — бесполезная затея.

Одна из проблем это отставание по фичам: вот например на что недавно натыкался https://github.com/libgit2/libgit2/issues/7210.

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

А где первая референсная реализация библиотеки? Потому и делают, что ее нет.

Только наоборот, сверху красивый фаянс (porcelain) а снизу страшные трубы (plumbing)

в git давно суют много нужного только корпоратам с большими монорепами гуано

Агрессивная оптимизация Git, чтобы разрабы не состарились при работе с большими репами типа Windows, это гуано? Ну, ну.. Linux как бы тоже не маленький…

Одна из проблем это отставание по фичам

То, что оно будет отставать, это как раз понятно. Хочется понять насколько.

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

Весьма странная фича. Но если она есть, значит определённо кому-то нужна. (=

Хочется понять насколько.

Ну вот пару дней назад приняли поддержку reftable.
Предлагаешь угадывать, нужно ли это лично тебе?

Предлагаешь угадывать, нужно ли это лично тебе?

Когда не просишь — ЛОР прям прорывает на гадания и советы, а тут… скучные вы! (%

Так надо было и не просить! :))

Ща бы уже давно «накидали».. «из непрошеного»... ;P ;)))