Нет сжатия локальной базы репозитория

[yarsergo]

Существует проблема
При большом числе инкрементальных выгрузок, или большом числе измененных объектов
последующие выгрузки начинают резко тормозить или выгрузка останавливается вовсе...

Пример - 200 версий... (на моей базе и компе примерно 40-50 версий в час - план 4-5 ч.)
запущено вечером, чтобы к утру всё прогрузилось...
в результате... утром обработка всё ещё идёт...
смотрим файл VERSION - только 37 версий прошло за 12 ч !? и в git ничего не выгрузилось!

Открываем репозиторий через GitGui чтобы выгрузить изменения...
сразу появляется окно - База данных репозитория требует сжатия (Compress DataBase) ... Ок

это же окно можно открыть через Repository - Compress DataBase

----- после сжатия (каждый час, делал параллельно с gitsync)
--- "оставшиеся" 150 изменений выгрузились "с плановой скоростью" за 3ч.

Хотелось бы иметь следующую функциональность

1. после каждых 10 (или N) изменений - делать push в git-репозиторий
2. делать сжатие (compress DataBase) локального репозитория... каждый раз после п.1

Вариант реализации [...]

1. для отправки - добавлять git push не в конце, а через каждые 10-20 изменений
   ( лучше конечно сделать и отдельный ключ ,
   т.е. сейчас он равен 0 (не определен) - push делается только в конце распаковки всех изменений

2. сжатие - после каждых N изменений из п.1 (или в конце)

• добавить команду git fsck (для каталога локального репозитория)
  (но я не уверен, что именно эта команда, извините есть что)

Дополнительный контекст
требование сжатия открываются в программе gitgui v 0.21 для git version 2.41.1 для windows.1

(но и раньше в 2020 г на более ранних версиях такое же было)

Спасибо за gitsync, давно им пользуюсь,
некоторые неудобства приходится обходить
через свои выгрузки на oscript и выполнение команд git
хотелось бы "улучшить" ситуацию для загрузки большого числа изменений

Живой пример - команда 4-5 разработчиков

• каждый день делает 10-20 изменений (а то и больше) в хранилище,
  за месяц (20-22 дня) это 200-440, за год х12 = 2400 - 5 280 изменений!

При начале использования GitSync для база за пару - тройку лет
загрузка превращается в боль на месяц-другой.

[asosnoviy]

после каждых 10 (или N) изменений - делать push в git-репозиторий

см плагин sync-remote там это есть. GITSYNC_REMOTE_PUSH_N_COMMITS

[nixel2007]

При начале использования GitSync для база за пару - тройку лет
загрузка превращается в боль на месяц-другой.

плагин limit, запуск в цикле, плюс запуск git gc должен решить проблему быстро. медленно - да, можно сделать доп плагин, который бы запускал git gc после пуша.

[nixel2007]

ну и всегда можно выгружать историю не с начала, а с N последних коммитов :)

[yarsergo]

спасибо за ответы...
git gc попробую... потому как git fsck не совсем то делает.

как выгружать порциями по 10 я знаю,
да, в gitsync есть и "начало" и "порция" изменений --minversion и --limit

Проблема то в том, что даже после любой порции в самом gitsync нет сжатия.

Поэтому да, приходится дополнительно свой скрипт писать с дополнительными шагами,
т.е. использовать свой скрипт на oscript + batch файлы для "полной" обработки выгрузки.

Далеко не все 1С-программисты это вообще заметят или догадаются сделать,
Если сжатие локального репозитория (добавить 1 команду git gc) сразу в gitSync
сразу после push - это уже будет большой + для всех, кто пользуется gitsync

Спасибо за понимание

[artbear]

Можно добавить эту функциональность (git gc) отдельным ключом в GITSYNC_REMOTE_PUSH_N_COMMITS