Небольшой эксперимент с precommit-ом

#1

Добрый день. Хотел задать вопрос в чате, но понял что это будет длиннопост.
Мы активно используем precommit1c. Настолько активно, что за полгода один репозиторий вырос до 680 Mb.
Я посмотрел код и нашел, вроде бы хорошую опцию - удалять оригинальные epf фалы. В этом и суть эксперимента.

Завел 2 репозитория. С одной и той же обработкой, но в одном добавил удаление epf

1
1.png1925×1036 96.9 KB

Добавляем обработку и коммитим.

2
2.png1918×1041 128 KB

Смотрим размер

3
3.png727×500 17.3 KB

А размеры одинаковые!!! Как так?!?! Ну ладно, может на первый раз так получилось. Повторим процедуру

4
4.png1920×1034 118 KB

5
5.png730×489 16.6 KB

Все равно одинаковый. Проверил, может все таки попадает файл обработки:

6
6.png1071×759 46.1 KB

7
7.png1071×757 40.8 KB

Попробовал удалить файлы классическим скриптом:

8
8.png580×522 20.5 KB

Итого - репозиторий похудел.
9

Поведение совсем не совпадает с ожидаемым… Может кто-то подсказать, что я делал не так?
Спасибо.

#2

похоже в исходном месте не вызывается git gc. Очень похоже - надо точно посмотреть на код precommit1c

#3

не вызывается. там git rm --cached для удаления из индекса.

#4

Он и не должен вызываться. Его гит сам запускает/предлагает запустить при необходимости. Это тяжёлая операция, на каждый коммит её дергать - вешалка.

1 Симпатия
#5

а git gc можно на диапазон коммитов?

#6

Ммм… а что мешает в .gitignore добавить *.epf?

#7

Совершенно согласен с @nixel2007 Операция GC не должна запускаться прекоммитом, это не его задача - следить за целостностью ссылок внутри базы гита.

#8

Потому что precommit обрабатывает изменения. Игнорируешь epf - нет изменений. Нет изменений - нет раскладки на исходники.

1 Симпатия
#9

Хм. Видишь я уже привык к тому что GitLab эту функциональность сам запускает https://docs.gitlab.com/ee/administration/housekeeping.html

А вот что я нашел месяц назад так это включение по умолчанию --aggressive - помогает со всякими ERP/УПП

В целом я бы кстати предложил вот еще какой вариант рассмотреть (подсмотрено у Димы Мармышева в GITConverter) - использование GIT LFS, вот функциональность GIT LFS для EPF очень похоже на функциональность precommit1c в момент precommit1c install

#10

Можно добавлять файл epf в индекс принудительно, через git add --force. Тогда разбор работает. Я вполне успешно работал по такому сценарию почти год.

#11

Да. Вот до этого я недавно добрался. И он почему-то не работает.

Локальный репозиторий - 15 Mb, на сервере 280. Но как бы все равно… Главное чтобы скачивался быстро.

Сейчас думаю нарисовать скрипт, который ночью запускать и бинарник выпиливать из истории.

#12

У нас в кабинете тоже полочка год на костыле (в буквальном смысле) держалась

#13

Имхо, надо перестать использовать precommit, и пользоваться нативной выгрузкой/загрузкой.

#14

А стандартную выгрузку повесить на прекоммит-хук )

#15

А стандартная выгрузка обратно соберет с совместимостью 8.2.16? И вроде стандартная выгрузка не разбирает ОФ

#16

Можно пользоваться “стандартной” через ванесса-раннер.
Он умеет и толстые разбирать, но это не точно :slight_smile: - я просто не помню точно

#17

Я помню была какая-то беда с необходимостью иметь базу, под которую обработка написана, иначе типы слетали

#18

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

но базу, да, в нужных случаях нужно иметь.

#19

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

#20

Такого не заметили. Но есть проблема когда кто-нибудь начинает разрабатывать обработку в другой базе. Решили очень просто - не используем типы) Назначаем программно

2 Симпатий