https://www.opennet.ru/openforum/vsluhforumID3/117575.html Представлен (https://lkml.org/lkml/2019/6/7/117) выпуск распределенной системы управления исходными текстами Git 2.22.0 (http://git-scm.com/). Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. <br><br><br><br><br>По сравнению с прошлым выпуском в новую версию принято 745 изменений, подготовленных при участии 74 разработчиков, из которых 18 впервые приняли участие в разработке. Основные (https://github.blog/2019-06-07-highlights-from-git-2-22/) новшества (https://github.com/git/git/blob/master/Documentation/RelNotes/2.22.0.txt):<br><br><br><br>- Доступный начиная с выпуска 1.18 новый режим переноса набора коммитов "git rebase --rebase-mer https://www.opennet.ru/openforum/vsluhforumID3/117575.html#27 Sat, 15 Jun 2019 11:40:59 GMT Стянет ровно столько, сколько попросишь, не больше и не меньше. Иди читай, как git работает.<br> https://www.opennet.ru/openforum/vsluhforumID3/117575.html#26 Tue, 11 Jun 2019 09:09:17 GMT &gt;Можно просто при клонировании глубину указывать, чтобы не тянуть ненужное<br><br>Это всё рано стянет ненужное, если хоть маленький кусочек старья по-прежнему используется.<br> https://www.opennet.ru/openforum/vsluhforumID3/117575.html#25 Mon, 10 Jun 2019 16:07:09 GMT Зачем терять историю? Пускай себе лежит. Можно просто при клонировании глубину указывать, чтобы не тянуть ненужное.<br> https://www.opennet.ru/openforum/vsluhforumID3/117575.html#24 Mon, 10 Jun 2019 05:35:40 GMT &gt; Речь про сумму .git и полного чекаута - т.к. с репой надо ещё и работать.<br><br>Соотношение-то какое? Если у тебя там огромные объекты, git будет тормозить, потому что он так устроен, а ты используешь его не по назначению. Если просто очень много объектов в истории, особых тормозов быть не должно.<br> https://www.opennet.ru/openforum/vsluhforumID3/117575.html#23 Sun, 09 Jun 2019 23:10:38 GMT Если нужно отделить "старую" историю от "текущей" истории,<br>то можно воспользоваться способом из книги Pro Git (https://git-scm.com/book/en/v2).<br>Способ описан в главе о команде Replace.<br> https://www.opennet.ru/openforum/vsluhforumID3/117575.html#22 Sun, 09 Jun 2019 21:25:57 GMT &gt; Добавлена опциональная возможность применения алгоритма хэширования SHA-256 вместо скомпрометированного SHA-1 при сборке Git в режиме "NewHash". Код для обхода дерева объектов изменён с учётом того, что имена объектов могут вычисляться не только с использованием SHA-1.<br><br>https://www.opennet.ru/opennews/art.shtml?num=50202<br> https://www.opennet.ru/openforum/vsluhforumID3/117575.html#21 Sun, 09 Jun 2019 21:24:11 GMT Однако ж получше других костылей типа fedpkg.<br> https://www.opennet.ru/openforum/vsluhforumID3/117575.html#20 Sun, 09 Jun 2019 19:54:35 GMT Во, это уже тема!<br>Речь про сумму .git и полного чекаута - т.к. с репой надо ещё и работать.<br>Можно поинтересоваться сколько примерно в вашей репе объектов, сколько времени длится коммит и rebase, и сколько клиентов тянет сервер?<br> https://www.opennet.ru/openforum/vsluhforumID3/117575.html#19 Sun, 09 Jun 2019 18:39:07 GMT А сожалению есть популярные репозитории, хранящие всю многогиговую историю. По-моему, единственное, что тут нужно сделать - это заморозить кодовую базу в смысле "не принимаем новые фичи в этот репозиторий", отребейзить все неслитые ветки, включая PR, на macter, пофиксить, перезаписывая историю, после чего cкопировать рабочую копию в новую папку и создать новый репозиторий. Старый переименовать в old-0, в initial commite дат ссылку на него. Пересоздать все ветки. Должно сильно уменьшить объём.<br>