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

precommit1c

#1

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

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

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

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

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


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


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

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

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


#2

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


#3

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


#4

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


#5

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


#6

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


#7

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


#8

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


#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

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