Зацепить или не зацепить - мерзавец - PullRequest
6 голосов
/ 29 июня 2011

Наша специализированная среда IDE выводит файлы XML с кодировкой, которая делает их похожими на двоичные файлы.Различия и слияния этих файлов завершаются неудачей.

Мы можем создавать ASCII-версии этих файлов с помощью команды tr.Я хотел бы перейти в состояние, в котором эти файлы всегда автоматически конвертируются в ascii, прежде чем они будут зафиксированы.

Я взял свою копию Контроль версий с помощью Git , и это от всего сердца меня предупреждаетот использования крючков, если мне действительно не нужно.

Должен ли я использовать крючок для этой цели?Или я могу сделать что-то еще, чтобы убедиться, что файлы всегда конвертируются перед коммитом?

Windows XP с msysgit 1.7.4

- = update = -

Спасибо всемза вашу помощь и терпение.Глядя на этот вопрос Я попробовал следующее, но это не работает:

echo "*.xrp    filter=xrp" > .git/info/attributes
git config --global filter.xrp.clean 'tr -cd '\''\11\12\15\40-\176'\'''
git config --global filter.xrp.smudge cat
git checkout --force

Файлы остаются неизменными после этого изменения конфигурации.Даже когда я удаляю и повторно извлекаю.

Команда tr, настроенная как чистая задача, работает изолированно.Доказательство:

$ head -n 1 cashflow/repo/C_GMM_CashflowRepo.xrp
ÿþ< ! - -   X M L   R e p o s i t o r y   f i l e   1 . 0   - - >

$ tr -cd '\''\11\12\15\40-\176'\' < cashflow/repo/C_GMM_CashflowRepo.xrp | head -n 1
<!-- XML Repository file 1.0 -->

Кто-нибудь может увидеть, что не так с моей конфигурацией?

Ответы [ 3 ]

6 голосов
/ 29 июня 2011

Одна проблема с хуками заключается в том, что они не распространяются.

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


В этом обсуждении чата OP Synesso сообщает об успехе:

.gitattributes:
*.xrp filter=xrp

~/.gitconfig:
[filter "xrp"]
clean = \"C:/Program Files/Git/bin/tr.exe\" -cd "\\''\\11\\12\\15\\40-\\176'\\'"
smudge = cat

Затем мне пришлось изменить файл, добавить, зафиксировать,удалить, оформить заказ ... и затем это было исправлено.:)

Обратите внимание, что для любой модификации, которая касается не только одного пользователя, но, возможно, любого пользователя, клонирующего этот репозиторий, я предпочитаю добавить (и зафиксировать) дополнительный файл .gitattributes, в которомФильтр объявляется вместо изменения файла .git/info/attribute (который не клонируется).

Из справочной страницы gitattributes :

  • Если вы хотите воздействовать только на один репозиторий (т. Е. Назначать атрибуты файлам, относящимся к рабочему процессу одного пользователя для этого репозитория), то атрибуты должны быть помещены в файл $GIT_DIR/info/attributes.
  • Атрибуты, которые должны контролироваться версиями и распространяться среди других репозиториев (т. Е. Атрибуты, представляющие интерес для всех пользователей), должны помещаться в файлы .gitattributes.
  • Атрибуты, которые должны влиять на все репозитории для одного пользователя, должны быть помещены в файл, указанный параметром конфигурации core.attributesfile.
  • Атрибуты для всех пользователей в системе должны быть помещены в файл $ (префикс) / etc / gitattributes.

http://git -scm.com/ docs / gitattributes


phyatt добавляет в комментарии :

Я сделал пример, подобный этомудля sqlite3.
Вы можете добавить его в правильные файлы двумя строками:

git config diff.sqlite3.textconv 'sqlite3 $1 .dump'
echo '*.db diff=sqlite3' >> $(git rev-parse --show-toplevel)/.gitattributes 

Подобные строки можно использовать для записи других путей git config.

2 голосов
/ 29 июня 2011

Если предпочитаемый формат редактирования - ASCII, и только для ваших сборок требуются двоичные файлы, я бы порекомендовал использовать правила сборки для создания двоичной версии из предпочтительного источника, который вы передадите в репозиторий.

Учитывая, что ваша IDE уже создает файлы в двоичном формате, я думаю, что лучше всего хранить их в хранилище в этом формате.

Вместо хуков, посмотрите на git help attributes, особенно diff и textconv, которые позволяют вам настраивать файлы, соответствующие определенным шаблонам, для использования альтернативных способов сравнения. Вы должны иметь возможность создавать рабочие различия ASCII без необходимости компромисса с тем, как вы храните файлы или редактируете их.

РЕДАКТИРОВАТЬ: Исходя из вашего комментария в другом месте, что "каждый второй байт равен 0", что предполагает, что файл является UTF-16 или UCS-2. См. Этот ответ для diff, который может обрабатывать Unicode: Можно ли заставить git распознавать файл UTF-16 как текст?

2 голосов
/ 29 июня 2011

Есть ли у diff шанс поработать с ними как есть (т.е. они просто содержат несколько странных байтов, но в остальном текст) или нет? Если это так, вы можете просто заставить git рассматривать их как текст с помощью .gitattributes. Если нет, то все же может быть лучше создать собственные сценарии diff и merge (которые будут использовать tr по мере необходимости для преобразования) и указать git использовать его, снова с .gitattributes.

В любом случае вы не будете использовать ловушки (которые предназначены для выполнения определенных операций), а .gitattributes, которые зависят от файла.

...