сокращённая версия git репозитория

git clone –depth

Спасибо, вроде более-менее работает, хотя пока не всё идеально. После того, как в Б делаю squash (там нужны только релизы, но не путь между ними), связь между веткой в Б и исходной веткой из А пропадает. Более того, когда я снова стягиваю (неосновную) ветку из Б, при то, что уже урезал её в А, она вообще как-то не видна (я работаю в tortoisegit, может быть в консоли видна, но под офтопиком у меня штуки 3 клиентов git, боюсь, как бы не сломать репозиторий вообще). Видимо, squash делать не получится и придётся довольствоваться тем, что история сокращена.

Не, так оно не сработало, т.к. я не смог залить это на гитлаб, чтобы у меня была там сокращённая версия. Ответ где-то тут,

https://stackoverflow.com/questions/50992188/how-to-push-a-shallow-clone-to-a-new-repo/50996201#50996201

или тут:

https://stackoverflow.com/questions/28983842/remote-rejected-shallow-update-not-allowed-after-changing-git-remote-url

Оба мне пока не особо нравятся, видимо, придётся ещё поработать над этим.

Гитовский pack содержит все файлы. Без файлов нет хэшей - нет и истории.

А могу я интересно в основном репозитории переместить начальную точку куда-то на начало этого года, чтобы история за прошлое «росла вниз» от этой точки? Т.е. как-то с помощью rebase, что ли? Тогда я сделаю полный клон всего репозитория А, назову репозиторием Б и удалю ветку, где история за прошлое.

2 Гига это не сверх много по нынешним меркам, стоит ли так заморачиваться?

Если есть возможность заставить всех обновиться, и в истории много мусора, типа файлов бэкапов, объектников, и прочего автогенерируемого шлака, то можно фильтрануть историю при помощи filter-branch или bfg (кажется так эти инструменты называются), репо станет поменьше.

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

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

Да. У тебя перепишется вся история (в плане хешей, таймстэмпы, диффы и сообщения можно оставить как были). Если этим репозиторием пользуешься ты один, то проблем вообще никаких.

Интересно. Я для нового репозитория создал новый remote, и так не заработало. А в старый смогу отправить, если клонировал с --depth N?

Не, надо всё переделывать, конечно, само не сделается. Как я бы сделал:

1. Вытащить весь репозиторий и сделать чекаут на нужном коммите.
2. Скопировать все файлы кроме .git в новый каталог. Сделать там git init, git add –all, git commit -m «Initial commit». Правда надо дату коммита проставить старую.
3. Сделать чекаут в первом репозитории на следующем коммите.
4. Скопировать все файлы в новый каталог. Сделать там коммит с сообщением и датой, идентичным исходному. Повторять пункты 3-4 до победного.

И теперь уже второму репозиторию добавляем remote и пушим его в исходный через –force.

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

Да вроде получилось, почему нет-то? Приблизительно так (делал в tortoisegit, команды не точные, мышью накликал)

git clone gitlab.com/a/b --depth 1
cd b
git branch моя-доработка
git checkout моя-доработка
echo aaaa > newfile
git add newfile
git commit -m "newmessage"
git push 

Т.е. если кто-то хочет что-то поделать в моём проекте, то он:

• делает форк на гитлабе
• далее по вышеприведённому сценарию
• merge request

И ему не надо скачивать 3.7 гб.

И ему не надо скачивать 3.7 гб.

А что в них?

В них содержимое репозитория git, к теме обсуждения отношения не имеет.

git help gc

В моём случае не поможет. Там много бинарных файлов (так надо). Можно было бы сделать squash и уменьшить их количество, т.к. файлы одни и те же, просто разных версий, и со временем они перестают быть нужными. Но похоже, что так нельзя - squash пересоздаёт всё, что было позже этого. В общем и целом fork + clone –depth N решает мой вопрос, хотя и не идеально, но жить можно. Всем спасибо за ответы!