Разработчики из компании Google представили (https://opensource.googleblog.com/2018/05/introducing-git-pr...) вторую версию коммуникационного протокола Git (https://mirrors.edge.kernel.org/pub/software/scm/git/docs/te...), который используется для обмена данными при удалённом подключении клиента к Git-серверу. При подготовке второй версии основное внимание было уделено повышению эффективности обмена данными, оптимизации для работы поверх HTTP и решению проблемы с расширяемостью. Реализация нового протокола уже принята в основной состав Git и ожидается в версии Git 2.18.
Среди ключевых новшеств отмечается обеспечение возможности фильтрации ссылок (веток и тегов) на стороне сервера, что позволяет отсеивать ссылки на удалённой стороне без необходимости загрузки списка всех ссылок. В первой версии протокола полный список ссылок в репозитории всегда отправлялся клиенту при выполнении любой команды извлечения, даже когда клиент обновлял только одну ветку ("git fetch origin master").
Для репозиториев, содержащих сотни тысяч ссылок (например, в репозитории Chromium насчитывается более 500 тысяч веток и тегов), сервер вынужден был передавать десятки мегабайт лишних данных, которые просто игнорировались на стороне клиента. Все эти заведомо игнорируемые данные приводили к напрасной трате времени и пропускной способности, особенно когда клиент обновлял в большом репозитории ветку с несколькими коммитами или просто проверял актуальность своей копии репозитория. Внедрение второй версии протокола в Google позволило до трёх раз ускорить выполнения холостых запросов (при отсутствии изменений) в репозитории Chromium и до восьми раз сократить объём отправляемого трафика с серверов googlesource.com.Вторым важным улучшением стало предоставление средств для расширения протокола, дающих возможность добавлять в протокол новые возможности по мере расширения функциональности инструментария. Например, расширения позволили добавить поддержку извлечения и отправки (fetch/push) символических ссылок (symref). Новая версия протокола также переработана для упрощения обработки соединений на клиентской стороне при применении в качестве транспорта HTTP (удалённый обработчик теперь функционирует как прокси).
При реализации второй версии протокола пришлось искать обходные пути для решения проблемы с отсутствием механизма согласования версии протокола между клиентом и сервером. Для транспорта "https://" выход был найден в форме добавления при запросе нового HTTP-заголовка "Git-Protocol: version=2", указывающего на поддержку второй версии протокола. Для транспорта "ssh://" передача версии протокла реализована через установки переменной окружения "GIT_PROTOCOL=version=2" на удалённой стороне после соединения (требует разрешения установки своих переменных окружения в конфигурации SSH).
Для транспорта "git://" с добавлением параметра с номером версии пришлось повозится, так как число параметров было ограничено после исправления в 2009 году ошибки, приводящей к зацикливанию. Проблема была решена "хаком", позволившим обойти ограничения через использование двух нулевых символов подряд, т.е. параметры передаются в виде "003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0".URL: https://opensource.googleblog.com/2018/05/introducing-git-pr...
Новость: https://www.opennet.dev/opennews/art.shtml?num=48622
> При реализации второй версии протокола пришлось искать обходные пути для решения проблемы с отсутствием механизма согласования версии протокола между клиентом и серверомГоворили же им.
> When you design protocols or file formats, make them sufficiently self-describing to be extensible. Always, always either include a version number
Можно было ведь добавить git2:// и не делать хак.
Расскажи об этом w3c. А то они бедные никак не догадаются добавить версию после протокола http.
> Расскажи об этом w3c. А то они бедные никак не догадаются добавить версию после протокола http.а им как раз и не надо - они-то (были) умные, и с 95го года добавили версию непосредственно в протокол.
А еще до 94го старательно определили что должен делать протокол с незнакомыми заголовками, поэтому добавление версии еще и обратную совместимость им не сломало.гитовские гугло-обезьянки умом не обладают, только жрать протянутый банан могут.
>> гитовские гугло-обезьянки умом не обладаютКак ты в дверные проемы пролазишь с таким самомнением?
Тяжко же жить, когда вокруг все раздражает. Береги себя, бро.
Чувак, я на твоей стороне ;)
Это замена одного хака на другой. И, вместо того, чтобы разруливать ситуацию автоматически, ты предлагаешь перенести ответственность на людей (считаю такой перенос ответственности признаком криворукости разработчика)
так если механизм не заложен - так и есть
так всё и будет автоматически, обновляешь свой гит на компе и всё он уже шлёт запросы к серваку по второму протоколу с фолбэком на первый. а с SSH конфигом к счастью автоматически ничего не происходит, только руками.
> например, в репозитории Chromium насчитывается более 500 тысяч веток и теговНа гитхабе в репе chromium написано 6 branches, где там 500 000 веток? Это безумное количество, никто бы не допустил такого числа веток. Или там 494 000 тегов и 6 веток? :)
Chromium как бы не на GitHub хостится, там только зеркало…
кривое зеркало, значит.
Черное зеркало...
>> например, в репозитории Chromium насчитывается более 500 тысяч веток и тегов
> На гитхабе в репе chromium написано 6 branches, где там 500 000
> веток? Это безумное количество, никто бы не допустил такого числа веток.
> Или там 494 000 тегов и 6 веток? :)На https://chromium.googlesource.com/chromium/src/+refs "всего" 14тыс. тэгов.
Может, укушенные CVS-ом и https://chromium.googlesource.com/All-Projects/ фрибсдешниками и их реп-всё-в-куче?
Разве у слитых веток ссылки не остаются? А уж делить-объединять ветки в git'е это сам Линус завещал.
>Для репозиториев, содержащих сотни тысяч ссылок (например, в репозитории Chromium насчитывается более 500 тысяч веток и тегов),Ваще замечательно, сначала они неправильно используют гит а потом делают новую версию протокола чтобы это было не так больно.
потрясающе, вы вот гит не разрабатываете, а делаете такие громкие заявляния
Поздравляю вы никогда не видели ребу хромиума на мнение о божественном гите имеете
Действительно: в каком вменяемом случае может понадобиться иметь репозиторий с тысячами веток? Мне кажется, разработчики Chromium перепутали Git с SVN: Git — это средство распределённой разработки, при использовании которого отдельные ветки пилятся независимо и в своих репозиториях, а в основной репозиторий пушатся только более-менее готовые изменения, оттестированные отдельно и представляющие ценность для хранения там. Именно так разрабатывается Linux и, не смотря на куда больший объём кода и число разработчиков, Git с хранением основного репозитория отлично справляется.Это как мелкософт, индусы из которого сначала решили залить в один репозиторий все составляющие windows проекты, а когда получили тормоящий репозиторий объёмом в сотни гигабайт, стали пилить под это специальную файловую систему.
В свн столько веток тоже не держа. Но там дело не столько в ветках сколько в тегах. С свн они его как раз не перепутали, они просто эмулируют логику свн поверх гита.
> не перепутали, они просто эмулируют логикуфайлопомойки поверх
>свн поверх гита.
Они просто не любят Микрософт, не хотят покупать ms-сервер, не хотят использовать msgvfs, но ... хотят, чтоб былО, как в микрософте.
Эх, ещё б они какую-нибудь механику докачки прикрутили...
Подождите, а что не прикрутили?! А я именно об этом гигантском улучшении подумал в первую очередь.
На диалапе сидишь?
Ты мазохист что ли, работать с большими репами на диалапе?Но даже если у тебя ничего другого нет, то есть опции, радикально ограничивающие количество качаемого: --depth и --single-branch
Завязывай с своим неосиляторским нытьём.
Как разок понадобится таки вытащить большую репу, сидя с отпуске с не сильно хорошей мобильной связью - по-другому запоёте.И алючиаи эти не помогут (а ветки ещё выгрести для начала надо).
Зачем Вы так жестоко ломаете картину мира диванному админу?
Кстати, хороший пример: inkscape. Кроме недостатка самого протокола, у них в репе ещё куча мусора. Склонировал 1,5 ГБ!!! Запустил git gc --aggressive - и оказалось, что на самом деле в репе всего-то 440 МБ.
Ведро линукс по прежнему нельзя скачать на плохом канале? Хорошо зделоли.
А чего,
$ git clone --depth 1 --branch linux-4.16.y \
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.gitне работает?
Да ему лишь бы сирануть, а решение проблемы до лампочки.
> А чего,
> $ git clone --depth 1 --branch linux-4.16.y \
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> не работает?Может человеку нужны все ветки, одна уже не вставляет
> git clone --depth 1Недавно была новость: 6 млн. git объектов! Тут, казалось, бы всего 1 последний коммит загружается. А придётся загрузить достаточно много: всего в 10 раз меньше чем полный клон со всеми миллионами объектов!
> --branch linux-4.16.y
Причём тут это? Никакого влияния на размер загружаемого не влияет. Просто сокращение: чекаутнуть вот эту ветку после клонирования.
Почему же, отлично работает. Только это 180 мегабайт. И на дерьмовом канале это может затянуться очень надолго. Может поведаете, что должно помешать разрабатывать ведро линукс на том же диалапе, кроме дерьмового протокола гита?
> Может поведаете, что должно помешать разрабатывать ведро линукс на том же диалапеАнониму с опеннета помешает то, что он и не собирался ничего разрабатывать.
Тот же, кто способен это делать, в состоянии нагуглить про git-bundle за 30 секунд даже с диалапа.
Используй дары смерти от Майкрософт
https://github.com/Microsoft/GVFS
> Используй дары смерти от Майкрософт
>\/Microsoft/GVFSМикрософт?... Микрософт и докачка? И работающаяя докачка?? Не шути так, мне больно!111 </<<<
https://www.kernel.org/cloning-linux-from-a-bundle.html
А inkscape? gcc? gimp? llvm? ...
Наконец-то!!!
Когда новые хеши будут? SHA1 уже на помойке истории. Небезопасная туфта.
- Хочу домой.
- Ну так пошли.
- Хочу домой быстро!
- Ну тогда побежали...(с) известный анекдот про мужика, нашедшего в пустыне лампу с джинном
И от какой же опасности ты собираешься тут защищаться новыми хешами?
Давай ты сначала продемонстрируешь подмену коммита на другой, и не тупо с рандомным мусором, а с компилирующимся вредоносным кодом, так чтобы sha1 был тот же. А потом поговорим о безопасности.
Давай ты сначала продемонстрируешь... MD2...
Давай ты сначала продемонстрируешь... MD4...
Давай ты сначала продемонстрируешь... MD5...
<==== вы находитесь здесь
Давай ты сначала продемонстрируешь... SHA1...
Давай ты сначала продемонстрируешь... SHA256...
Давай ты сначала продемонстрируешь... SHA384...
Давай ты сначала продемонстрируешь... SHA512...
...
Даже для md5 такое нелегко продемонстрировать, если ты не Гугл. Сложность md5 preimage attack - 2^122.
> Давай ты сначала продемонстрируешь... MD2...
> Давай ты сначала продемонстрируешь... MD4...
> Давай ты сначала продемонстрируешь... MD5...Так где эксплойты то? Так и не было? Впрочем, ничего нового.
> обеспечение возможности фильтрации ссылок (веток и тегов) на стороне сервераНаступило щястье!
> Разработчики из компании Google представилиКакого xpeна? Кто они такие чтобы представлять? Git - это разработка Линуса Торвальдса, а не Google. Что это еще за фокусы? Какие новые протоколы? Они там упоролись? Или это их внутренний форк для своих нужд? Если они это не толкают в массы, то пусть месят свой форк и не лезут к остальным. Линус сам знает как лучше развивать Git.
>> Разработчики из компании Google представили
> Какого xpeна? Кто они такие чтобы представлять? Git - это разработка Линуса
> Торвальдса, а не Google. Что это еще за фокусы? Какие новыеЛТ уже довольно давно не у руля https://lwn.net/Articles/145123/ .
> свой форк и не лезут к остальным. Линус сам знает как
> лучше развивать Git.Виновые кеши приняли, и гуглёвые протоколы схавают.
Это открытый софт. Кому что надо - тот и разрабатывает.
> требует разрешения установки своих переменных окружения в конфигурации SSHвангую, что скоро вскроется уязвимость