Добавить флаг удаления файлов обработок из индекса git

[nixel2007]

Всем привет.
Разбор файлов идет через вызов из корневого каталога репозитория

oscript libs/precommit1c/v8files-extractor.os --git-precommit "source/processings/source"

У себя пытаюсь реализовать задачу хранения в репозитории только исходников обработок, без бинарных epf и ert.

Для этого я добавил данное изменение (полное сравнение репозиториев), которое после разбора обработок на исходники удаляет оригинальный бинарный файл из индекса git.

На поведение по умолчанию такой подход не тянет, поэтому на мой взгляд стоит добавить некий флаг в вызов. Если поддерживаете идею, то можно обсудить имя и позицию этого флага, и я могу сделать MR с этими изменениями + добавление описания параметра + README (либо просто перенесите мой код в основной репо).

[artbear]

Да, можно добавить данное поведение.
Предлагаю название флага --remove-orig-bin-files (кратко -rm-orig-bin)

@pumbaEO @EvilBeaver что скажете?

[pumbaEO]

Хм, не совсем понятен принцип, сам бизнес процесс. Если постоянно удалять из индекса epf файл, то он всегда будет у нас отображатся как НЕ добавляенный, т.е. git add . мы не сделаем, а если и сделаем то туда попадет 20, 30, n обработок, а не 1 обработка которая была изменена. Имхо правильней тогда добавить в исключение epf файл потом просто разбирать необходимые и измененные файлы.

[EvilBeaver]

@pumbaEO балбесы мы. игнор же есть, имхо, это то, что нужно

[artbear]

@pumbaEO При добавлении файла в исключения сразу возникает вопрос - каким образом будет выполнен прекоммит для этого файла, ведь логично, что этот файл в коммит не попадает?
или я что-то не понял?

[nixel2007]

@EvilBeaver при использовании .gitignore нельзя добавить файл через add.

[nixel2007]

@pumbaEO хм... в принципе в рамках своего проекта я готов делать git add .\source\cf\, но в общем случае это не совсем удобно, согласен.

Глобально нет ничего страшного от использования git add ., ведь если вы не меняли обработки, то и исходники обработок у вас не поменяются. Критичный минус здесь в том,что увеличивается время на коммит, плюс требуется всегда соответствующие исходникам версии обработок (но я это я планирую реализовать через postrecieve-хук с автобилдом обработок в директорию).

UPD

Имхо правильней тогда добавить в исключение epf файл потом просто разбирать необходимые и измененные файлы.

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

[artbear]

Если постоянно удалять из индекса epf файл, то он всегда будет у нас отображатся как НЕ добавляенный, т.е. git add . мы не сделаем, а если и сделаем то туда попадет 20, 30, n обработок, а не 1 обработка которая была изменена

@pumbaEO прав.
@nixel2007 как разруливать сценарий, когда у нас несколько epf-файлов?
наши епф-файлы всегда будут числиться измененными?

[nixel2007]

@pumbaEO @artbear
у git add есть флаг -f, который добавляет файл в обход .gitignore.

Получилось реализовать схему вот в такой конфигурации:
Содержимое файла .gitingore

source/processings/bin/**
!source/processings/bin/.gitkeep

В source/processings/bin/ положено несколько файлов epf.
git add . выдает отсутствие изменений.
git add -f source/processings/bin/ЗаполнитьАналитикиПоФакту.epf добавляет файл в индекс, через git status файл помечается как new
Вызов oscript -encoding=utf-8 libs/precommit1c/v8files-extractor.os --git-precommit "source/processings/source" выдает следующий лог (его немного покорябило при копировании из терминала, но смысл ясен):

ОТЛАДКА - Передана команда: --git-precommit
ОТЛАДКА - ВыходнойКаталог = source/processings/source
ОТЛАДКА - Запускаю git diff-index
ОТЛАДКА - cmd /C "git diff-index --name-status --cached HEAD > "C:\Users\na_gryzlov\AppData\Local\Temp\fotdfsbh.ko4.tmp" 2>&1"
ОТЛАДКА - Код возврата: 0
ОТЛАДКА - Вывод git diff-index: A       source/processings/bin/ЗаполнитьАналитикиПоФакту.epf

ОТЛАДКА - ЖурналИзмененийГит:
ОТЛАДКА -       A       source/processings/bin/ЗаполнитьАналитикиПоФакту.epf
ОТЛАДКА -
ОТЛАДКА - Получен из журнала git файл source/processings/bin/ЗаполнитьАналитикиПоФакту.epf
ИНФОРМАЦИЯ - Подготовка выгрузки файла D:\git\bit_vuz\source/processings/bin/ЗаполнитьАналитикиПоФакту.epf в каталог D:\git\bi                                                                                                                                        t_vuz\source/processings/source
ОТЛАДКА - Создаем новый каталог D:\git\bit_vuz\source\processings\source\ЗаполнитьАналитикиПоФакту
ОТЛАДКА - Запускаем распаковку файла
ОТЛАДКА - КлючСоединенияСБазой /F"C:\Users\na_gryzlov\AppData\Local\Temp\jw0zxsbd.xzx.tmp\v8r_TempDB"
ОТЛАДКА - ИмяПользователя <>
ОТЛАДКА - Путь к V8Reader: D:\git\bit_vuz\libs\precommit1c\v8Reader\V8Reader.epf
ОТЛАДКА - Командная строка V8Reader: /C"decompile;pathtocf;D:\git\bit_vuz\source\processings\bin\ЗаполнитьАналитикиПоФакту.epf                                                                                                                                        ;pathout;D:\git\bit_vuz\source\processings\source\ЗаполнитьАналитикиПоФакту;ЗавершитьРаботуПосле;"
ОТЛАДКА - Проверяю равенство КлючСоединенияСБазой() = КлючВременногоКонтекста() и Не ВременнаяБазаСуществует()
ОТЛАДКА - КлючСоединенияСБазой() /F"C:\Users\na_gryzlov\AppData\Local\Temp\jw0zxsbd.xzx.tmp\v8r_TempDB"
ОТЛАДКА - КлючВременногоКонтекста() /F"C:\Users\na_gryzlov\AppData\Local\Temp\jw0zxsbd.xzx.tmp\v8r_TempDB"
ОТЛАДКА - ВременнаяБазаСуществует() Нет
ОТЛАДКА - Равенство выполняется.
ОТЛАДКА - Создаю временную базу. Путь C:\Users\na_gryzlov\AppData\Local\Temp\jw0zxsbd.xzx.tmp\v8r_TempDB
ОТЛАДКА - Создаю файловую базу C:\Users\na_gryzlov\AppData\Local\Temp\jw0zxsbd.xzx.tmp\v8r_TempDB
ОТЛАДКА - "C:\Program Files (x86)\1cv8\8.3.6.2332\bin\1cv8.exe" CREATEINFOBASE File="C:\Users\na_gryzlov\AppData\Local\Temp\jw                                                                                                                                        0zxsbd.xzx.tmp\v8r_TempDB" /Out"C:\Users\na_gryzlov\AppData\Local\Temp\jw0zxsbd.xzx.tmp\log.txt"
ОТЛАДКА - файл информации:
Создание информационной базы ("File="C:\Users\na_gryzlov\AppData\Local\Temp\jw0zxsbd.xzx.tmp\v8r_TempDB";Locale = "ru_RU";") у                                                                                                                                        спешно завершено

ОТЛАДКА - "C:\Program Files (x86)\1cv8\8.3.6.2332\bin\1cv8.exe" ENTERPRISE /F"C:\Users\na_gryzlov\AppData\Local\Temp\jw0zxsbd.                                                                                                                                        xzx.tmp\v8r_TempDB" /Out"C:\Users\na_gryzlov\AppData\Local\Temp\jw0zxsbd.xzx.tmp\log.txt" /WA+ /DisableStartupMessages /Disabl                                                                                                                                        eStartupDialogs /RunModeOrdinaryApplication /Execute "D:\git\bit_vuz\libs\precommit1c\v8Reader\V8Reader.epf" /C"decompile;path                                                                                                                                        tocf;D:\git\bit_vuz\source\processings\bin\ЗаполнитьАналитикиПоФакту.epf;pathout;D:\git\bit_vuz\source\processings\source\Запо                                                                                                                                        лнитьАналитикиПоФакту;ЗавершитьРаботуПосле;"
ОТЛАДКА - файл информации:

ОТЛАДКА - Код возврата равен 0
ОТЛАДКА - Вывод 1С:Предприятия -
ОТЛАДКА - Очищаем каталог временной ИБ
ИНФОРМАЦИЯ - Завершена выгрузка файла D:\git\bit_vuz\source/processings/bin/ЗаполнитьАналитикиПоФакту.epf в каталог D:\git\bit                                                                                                                                        _vuz\source/processings/source
ОТЛАДКА - Удаляю файл из индекса
ОТЛАДКА - cmd /C "git rm --cached "D:\git\bit_vuz\source/processings/bin/ЗаполнитьАналитикиПоФакту.epf" > "C:\Users\na_gryzlov                                                                                                                                        \AppData\Local\Temp\m2ihx4yx.1fq.tmp" 2>&1"
ОТЛАДКА - Код возврата: 0
ОТЛАДКА - Вывод git rm --cached: rm 'source/processings/bin/ЗаполнитьАналитикиПоФакту.epf'

ОТЛАДКА - Запуск git add для каталога D:\git\bit_vuz\source\processings\source\ЗаполнитьАналитикиПоФакту
ОТЛАДКА - cmd /C "git add --all D:\git\bit_vuz\source\processings\source\ЗаполнитьАналитикиПоФакту > "C:\Users\na_gryzlov\AppD                                                                                                                                        ata\Local\Temp\x1dr5g3g.wzs.tmp" 2>&1"
ОТЛАДКА - Код возврата: 0
ОТЛАДКА - Вывод git add:

В git status исходники есть, epf нет.
Вроде схема реализована.
Что скажете?

[artbear]

@nixel2007 Да, результат похож на правильный :)
Смущает только то, что ГУИ-клиенты гит коряво работают с подобными игнор-файлами.
Например, в SourceTree нельзя одновременно посмотреть на измененные отслеживаемые файлы и игнорируемые файлы :(
Плюс к этому психологически неудобно работать с игнорируемыми файлами :(

[nixel2007]

@artbear

Плюс к этому психологически неудобно работать с игнорируемыми файлами :(

Ну, так-то и добавление/удаление из индекса гита это всего лишь костыль для автоматизации процесса. Чем-то приходится жертвовать :)
По поводу GUI... В github for windows и штатном git GUI тоже нет возможности добавить игнорируемый файл. Видимо, из коробки в такой схеме можно работать только с консоли.

Можно в документации эту фичу/флаг дополнительно расписать, указать данные сложности. Ведь, как говорится, задокументированный баг не является ошибкой. :)

[EvilBeaver]

Имхо, смысл проекта precommit - это когда мы в репо храним Обработки, но перед коммитом Обработки, делаем еще пару действий. Т.е. scope проекта - не убрать обработки и не заигнорить, а положить в git. Если задача хранить только сорцы, а потом их после клонирования как-то собирать в EPF, то надо сам смысл проекта пересмотреть.

[nixel2007]

На мой взгляд, хранение бинарников под гитом - вообще не очень хорошая идея (мне, например, очень сильно глаза мозолит огромный 1CD в хистори проекта precommit, замедляющий clone и работу через submodule).
Так же без системы автосборки обработок мы либо вообще лишаемся клевой возможности редактирования обработок без 1С прямо в браузере на гитхабе/в блокноте на PC, либо рискуем поретереть изменения в исходниках. Используя же автосборку обработок наличие самих epf под гитом тоже может принести головную боль.

Давайте я опишу полный work-flow, который я хочу построить у себя на работе.

1. Под git лежат только исходники конфигурации и "дополнительных отчетов и обработок", без их бинарных представлений.
2. Редактирование файлов конфигурации и обработок возможно как и из 1с с последующей выгрузкой в исходники, так и с браузера/блокнота/чего угодно, что может редактировать текст.
3. При получении исходников обработок через post-recieve хук обработки собираются обратно в bin и готовы к редактированию из 1с.
4. При мерже изменений в master системой CI (в моем случае gitlab CI) изменения в конфигурации силами самописного скрипта на osrcipt и 8.3.7 инкрементно деплоятся в продакшн (уже реализовано).
5. При мерже изменений в master какой-либо обработки (а точнее ее исходников) тем же CI происходит билд обработки и помещение ее в справочник "Дополнительные отчеты и обработки" (в процессе реализации).

Соответственно precommit (или его части) я хочу использовать для реализации пунктов 2 (в части обработок), 3 и 5.

Согласен, что описываемая в этих пунктах задача несколько шире изначальной концепции precommit, однако же и билд обработок из исходников (опция --compile) не относится к задаче разбора бинарников. Так что, на мой взгляд, концепция не хранения бинарников обработок в гите не (сильно) противоречит текущему смыслу проекта, как его озвучил @EvilBeaver.

Извиняюсь, за стену текста :)

[nixel2007]

Продолжая разговор из EvilBeaver/oscript-library#2

Вот и получается, что правильнее как раз перенести упоминаемый флаг как доп.параметр в команду ИзмененияПоЖурналуГит

@artbear
По флагу - такое поведение может потребоваться только в ИзмененияПоЖурналуГит или теоретически в остальных режимах работы скрипта она тоже возможна? Другими словами, флаг нужен для всех команд, или только для той, что работает по индексу git?