Делает ли долгая история фиксаций медленное клонирование репозитория Git медленным?

#git #repository #commit #git-commit

Вопрос:

У меня есть репозиторий Git с очень длинной историей фиксации. Для простоты скажем, что мое старое репо содержит только главную ветвь с коммитами COMMIT-1…ОБЯЗАТЕЛЬСТВО-10000. Мне было интересно, смогу ли я сократить время, необходимое для клонирования, и необходимое пространство для локального репозитария, если я создам «копию» данного репозитория, создав большую «раздавленную» фиксацию (ФИКСАЦИЯ 1*), которая включает все изменения до сих пор.

Набросок модификации:

 CURRENT REPO     ----->     NEW REPO
COMMIT-10000                COMMIT-1*
     |
    ...
     |
  COMMIT-1

Действительно ли это улучшит скорость клонирования или требования к памяти?

Существуют ли какие-либо общеприменимые решения для улучшения этих вещей?

1. Чтобы увеличить время клонирования, не удаляя историю вашего репозитория в центральном репозитории, см. --depth опцию для git clone . Погуглите git clone depth , чтобы увидеть примеры того, когда это использовать.

Ответ №1:

Фиксации в репозитории-это история; больше фиксаций = больше истории = больше общих данных = больше общего времени. Итак: да, если вы создадите новое хранилище только с одной фиксацией, содержащей один снимок всех файлов, он всегда будет по крайней мере немного меньше, чем ваш старый репозиторий с 10 000 снимками, содержащими все файлы.

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

Например, предположим, что первая фиксация содержит 10 001 другой файл, а каждая последующая фиксация в моментальном снимке удаляет один файл, сохраняя остальные файлы. Тогда в новом репозитории будет один файл в одном снимке, в то время как в старом фиксаторе будет 10 001 файл в 10 000 снимках.

На практике единственный способ узнать это-попробовать.

1. Спасибо за ответ @torek. Поэтому мне кажется, что это один из общеприменимых способов, возможно, повысить скорость клонирования репозитория git и уменьшить необходимое для этого пространство. Существуют ли какие-либо другие общеприменимые решения для улучшения этих вещей?

2. Проблема с созданием нового репозитория с несвязанной историей, конечно, заключается в том, что теперь у вас есть новый репозиторий с несвязанной историей: вы больше не можете вернуться во времени так, как могли раньше. Мелкий клон-это тот, который знает, что существует больше истории, но не включает ее; мелкие клоны имеют некоторые ограничения, но, вероятно, здесь более полезны.