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

Question

[Алексей]

Звучит вопрос, конечно, немного забавно - почему что-то висит при большой обработке...
Пробуем перевести большой репозиторий 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 сек при необходимости просмотра истории файла трудно описать...

Answer 1

[Сергей Кузнецов]

А после перевода из SVN в Git вы делали сжатие репозитория?
git gc --prune=now --aggressive

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

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

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

Comments

[Алексей]

extensions выбрал за возможность отображения CP866.
За совет по клиенту спасибо, первое впечатление очень позитивное, поищу, есть ли поддержка кодировки или надо будет пробовать внешние редакторы/сравнение.
В папке приложения файл cp866.enc есть, но во встроенном редакторе с ходу не получилось просмотреть 866 кодировку.
Попробовал несколько коммитов с сообщениями в 866 - они в клиенте отобразились корректно.

[Алексей]

По репозиторию - попробовал сжатие/очистку, за пол-часа репозиторий обработался, но, честно говоря, особого эффекта не дало.
Мне кажется, что на искусственном репо, в котором bash-скрипт аккуратно, один за одним, корректно укладывает коммиты из svn, особо не будет предмета для оптимизации.
Только поджать по месту, но в этом особо нет необходимости.

Основной недостаток репозитория в том, что практически все файлы сконцентрированы в одной папке.
git-sizer показывает это большим "беспокойством". Придется обсуждать структуру репозитория с разработкой.

Processing blobs: 151372
Processing trees: 55915
Processing commits: 25504
Matching commits to trees: 25504
Processing annotated tags: 0
Processing references: 3
| Name                         | Value     | Level of concern               |
| ---------------------------- | --------- | ------------------------------ |
| Overall repository size      |           |                                |
| * Trees                      |           |                                |
|   * Total size               |  30.6 GiB | ****************               |
|   * Total tree entries       |   846 M   | ****************               |
|                              |           |                                |
| Biggest objects              |           |                                |
| * Trees                      |           |                                |
|   * Maximum entries      [1] |  50.4 k   | !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
|                              |           |                                |
| Biggest checkouts            |           |                                |
| * Number of files        [2] |  55.6 k   | *                              |

Эксперимент по совету из документации сайзера (Does the repository include gigantic trees (directories)?), с разбиение на папки по 2-3 файлов тысячи показал совсем другую картину (в лучшую сторону).

[Алексей]

По разделению истории - спасибо, интересно было попробовать.
Общая история после replace правильно склеилась, только как-то странно повела себя после удаления remote.
Хотел посмотреть что именно произойдет после удаления remote с бОльшей частью отсеченной истории. Ожидал, что "обрезанный" основной репозиторий вернется к состоянию до разделяющего коммита (после rebase), и можно будет remote подключать/отключать по мере необходимости.
А репозиторий вернулся к полному начальному варианту со всеми коммитами, как до процедуры rebase.

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

В целом, видимо, пока вопрос откладывается до обсуждения реструктуризации репозитория.
Еще раз спасибо за помощь!

[Сергей Кузнецов]

Я не считаю Проводник файловым менеджером и практически не пользуюсь им. Поэтому гит-клиент в виде примочки к проводнику даже не рассматривал. FAR Manager или Midnight Commander — наше всё

В своё время нужно было работать с файлами в однобитной кодировке win-1251 и оказалось, что единственный клиент который умел отображать такие файлы это SmartGit.

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

[Сергей Кузнецов]

практически все файлы сконцентрированы в одной папке.

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

Answer 2

[Алексей]

Итого, варианты с разными структурами репозитория показали, что наша причина была именно в структуре.

Структуру 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   | **************                 |

Большое спасибо всем за помощь!

Answer 3

[Иван]

К сожалению нет, но есть несколько способов, которые могут помочь вам ускорить или облегчить просмотр истории файла в 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 году. Это может быть полезно, если вы знаете примерное время, когда файл был изменен.

Answer 4

[Freeman]

Вроде бы хранение графа коммитов сильно ускоряет git log. Стоя в репе, выполняем команду:
git commit-graph write --reachable --split=replace