Почему подвисает Git Extensions и git log при вывода истории файла из большого репозитория?

Звучит вопрос, конечно, немного забавно - почему что-то висит при большой обработке...
Пробуем перевести большой репозиторий Subversion в Git.
~ 50k файлов, 30к коммитов, 10 лет.

Полученный репозиторий в Git клонирую локально, в клиенте Git Extensions запускаю просмотр истории файла — клиент уходит в серое окно, процессор локальной машины уходит в высокую нагрузку. Другие клиенты ведут себя похоже.

В GE выбираю F12 посмотреть команду.

git -c log.showSignature=false log --format="????%H" --name-only --follow  --find-renames --find-copies -- "src/filename"


Пробую эту команду в cmd.exe, убираю ключи, оставляю только git log "src/filename" — гит быстро (пара секунд) выводит найденные недавние коммиты (попался файл недавний), но не завершается, а висит около 20-30с сек в "Waiting for data... (^X or interrupt to abort)" с той самой нагрузкой процессора — видимо смотрит оставшуюся часть репозитория.

Перебирая клиентов заметил, что клиент Sublime Merge ведет себя немного иначе с историей — отображает получаемую информацию по мере получения коммитов в процессе исполнения команды и не виснет. Видимо, умеет параллельно отображать итоги, не дожидаясь завершения основной команды.

С ходу в Git Extensions не нашел возможности какой-то из настроек повторить такое поведение — "не висеть недоступно до конца выполнения команды".

Не подскажете, можно ли все же Git Extensions попросить не виснуть до завершения базовой команды?
Радость разработчиков от необходимости ожидания 30 сек при необходимости просмотра истории файла трудно описать...
  • Вопрос задан
  • 98 просмотров
Решения вопроса 2
sergey-kuznetsov
@sergey-kuznetsov Куратор тега Git
Автоматизатор
А после перевода из SVN в Git вы делали сжатие репозитория?
git gc --prune=now --aggressive

Думаю проблема где-то тут. Ведь в репозитории ядра Linux больше миллиона коммитов, но это не мешает разработчикам с ним работать.

Я не понимаю чего вы нашли в Git Extensions. Мне кажется это худший инструмент для Git, после TortoiseGit.
Рекомендую SmartGit или Git-плагин в средах разработки от JetBrains.

Ещё, как вариант, обрезать старую историю. Можно сделать два репозитория — архивный и актуальный. В последнем допустим оставить коммиты за последние пару лет. Кому вдруг понадобится покопаться в древних коммитах, тот всегда сможет прицепить старую историю. Рецепт как это сделать есть официальном учебнике.
Ответ написан
amk4
@amk4 Автор вопроса
Итого, варианты с разными структурами репозитория показали, что наша причина была именно в структуре.

Структуру SVN с большой папкой 50к файлов, в которую постоянно коммитились изменения, никак не удалось довести но приемлемого отклика при работе со всеми клиентами.

Снижение размера до основных 5к файлов, с _постепенным_ ростом до 14к кардинально изменило положение.
Даже простой extensions начал практически нормально работать с репозиторием и историей, количество коммитов не особо влияло.

D:\gittest\beta>git-sizer
Processing blobs: 64489
Processing trees: 51241
Processing commits: 23414
Matching commits to trees: 23414
Processing annotated tags: 0
Processing references: 3
| Name                         | Value     | Level of concern               |
| ---------------------------- | --------- | ------------------------------ |
| Overall repository size      |           |                                |
| * Trees                      |           |                                |
|   * Total size               |  7.85 GiB | ****                           |
|   * Total tree entries       |   216 M   | ****                           |
|                              |           |                                |
| Biggest objects              |           |                                |
| * Trees                      |           |                                |
|   * Maximum entries      [1] |  14.3 k   | **************                 |


Большое спасибо всем за помощь!
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
@Naiivi
К сожалению нет, но есть несколько способов, которые могут помочь вам ускорить или облегчить просмотр истории файла в git extensions. Они включают в себя:

1) Установить опцию --max-count для git log, чтобы ограничить количество показываемых коммитов. Например, git log --max-count=10 "src/filename" покажет только последние 10 коммитов, в которых был изменен файл. Это может сократить время ожидания и нагрузку на процессор.
2) Установить опцию --no-pager для git log, чтобы отключить использование программы less для показа вывода. Например, git log --no-pager "src/filename" покажет историю файла без задержки и возможности прокрутки. Это может быть полезно, если вы хотите просто посмотреть последние изменения файла.
3) Использовать фильтр по дате для git log, чтобы показать только коммиты, сделанные в определенный период времени. Например,
git log --since="2020-01-01" --until="2020-12-31" "src/filename"
покажет только коммиты, сделанные в 2020 году. Это может быть полезно, если вы знаете примерное время, когда файл был изменен.
Ответ написан
Комментировать
Vapaamies
@Vapaamies
Разработчик будущей ОС для ПК размером 250 МБ
Вроде бы хранение графа коммитов сильно ускоряет git log. Стоя в репе, выполняем команду:
git commit-graph write --reachable --split=replace
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы