Git Push очень медленно для огромного репо

Question

У меня та же проблема, что и в - git push очень медленный для ветви , но ответ там не подходит для моей ситуации.

Я работаю против корпоративного GitHubс очень большим репо.Мой процесс выглядит следующим образом:

1) Извлечение из мастера

2) Создание новой ветви

3) Фиксация

4) Нажмите ветку, чтобы создатьзапрос на извлечение.

При нажатии на ветвь (4) он хочет записать более 1 000 000 объектов, которые занимают около 3 ГБ, когда сделанный мной коммит должен был изменить только 1 строку.

Если я пойдув пользовательский интерфейс GitHub и создайте ветку с тем же именем, что и в (2), из пользовательского интерфейса, а затем нажмите на эту ветвь, нажатие занимает менее секунды.Само собой разумеется, что изменения между master и моей веткой очень незначительны (большой файл не добавлен или удален).

Что я могу сделать, чтобы Git выдвигал только соответствующие данные, а не весь репо?

Git в Windows ver 2.17.0

Answer 1

Вы можете попробовать тот же толчок с помощью:

• Git для Windows 2.21
• git config --global pack.sparse true (я представил вариант pack.sparseздесь в марте 2019 г.)

Этот параметр относится к этим пачам и реализован в commit d5d2e93 , который включает комментарий:

Эти улучшения будут иметь еще большие преимущества в сверхбольшем репозитории Windows.

Это должно быть интересно в вашем случае.

См. " Изучение новых границ производительности Git push "от Деррик Стоули

A git push обычно отображает что-то вроде:

$ git push origin topic
Enumerating objects: 3670, done.
Counting objects: 100% (2369/2369), done.
Delta compression using up to 8 threads
Compressing objects: 100% (546/546), done.
Writing objects: 100% (1378/1378), 468.06 KiB | 7.67 MiB/s, done.
Total 1378 (delta 1109), reused 1096 (delta 832)
remote: Resolving deltas: 100% (1109/1109), completed with 312 local objects.
To https://server.info/fake.git
* [new branch] topic -> topic

«Перечисление» означает:

Git создает упаковочный файл, содержащий коммит, который вы пытаетесь выдвинуть, а также все коммиты, деревья и большие двоичные объекты (вместе объекты)) что сервер должен будет понимать этот коммит.
Он находит набор коммитов, деревьев и BLOB-объектов, такой что каждый гкаждый доступный объект находится в наборе или известен как находящийся на сервере.

Цель состоит в том, чтобы найти правильную "границу"

Неинтересные коммиты, которые являются прямыми родителями интересных коммитов, формируют границу

Old:

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

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

Новый

Старый алгоритм рекурсивен: он берет дерево и запускает алгоритм на всех поддеревьях.

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

Новая прогулка по деревьям рекурсивно исследует пути, содержащие интересные и неинтересные деревья.
Внутри деревьев в B у нас есть поддеревья с именами F и G.
Оба набора имеют интересные и неинтересные пути, поэтому мы вернемся к каждому набору.Это продолжается в B/F и B/G.Набор B/F не вернется в B/F/M или B/F/N, а набор B/G не вернется в B/G/X, но не B/G/Y.

Answer 2

Звучит как проблема с окончанием строки.

Если вы извлекаете репо на компьютере с Windows, окончания строк Unix (LF) будут преобразованы в Windows (CR LF).
Когда вы фиксируете, Git будет думать, что все файлы были обновлены, потому что всеокончания строк будут изменены.

Вы можете настроить Git для управления этим с помощью этой команды:

git config --global core.autocrlf true