Git эквивалент расширения ключевого слова subversion $URL $

Я рассматриваю переход из подрывной программы в git. Одна из вещей, которые мы используем подрывную деятельность для наших системных администраторов для управления такими вещами, как файлы конфигурации. С этой целью мы помещаем $URL$ в каждый файл, который расширяется до расположения файла в дереве subversion. Это позволяет администраторам смотреть на файл на каком-то произвольном хосте и определять, в каком дереве он появился.

Самый близкий аналог, который я мог найти, - это gitattributes. Существует директива filter=, но кажется, что git не сообщает фильтру, какое имя файла он фильтрует, что необходимо было бы превратить $URL$ в путь.

Существует также директива ident, которая превратит $Id$ в хэш блоба. Это может быть полезно, если можно было отобразить это обратно в путь, но мой git -fu недостаточно силен.

Любые предложения?

Рабочий процесс выглядит следующим образом:

  • Администратор фиксирует изменения в репозитории VCS
  • Администратор обновляет центральное место, которое провело репо
  • Администратор переносит изменения на хост с помощью cfengine

ОТВЕТЫ

Ответ 1

Как упоминалось в "Имеет ли git что-нибудь вроде svn propset svn:keywords или перехватчиков pre-/post-commit?" , git не поддерживает расширение ключевого слова.

"Работа с расширением ключевого слова SVN с помощью git -sv" предоставляет решение на основе git config filter (которое не совсем то, что вы хотите) и/или gitattributes.

Ближайший пример, если расширение файловой информации я нашел, что оно все еще основано на методе smudge/clean, с этим git хэш-фильтром, но чистая часть удаляет его из файла, и путь не найден.

Этот поток фактически говорит об этом (а также упоминает некоторые команды git -fu, которые могут содержать то, что вы ищете, Я их не тестировал):

В любом случае, smudge/clean не дает немедленного решения проблемы из-за небольших технических недостатков:

  • Фильтр smudge не передается имя проверяемого файла, поэтому невозможно точно определить идентификатор фиксации.
    Однако это смягчается тем фактом, что "smudge" запускается только для измененных файлов, поэтому последняя фиксация является необходимой.

  • Фильтр smudge не передается идентификатором фиксации. Это немного более серьезно, так как эта информация нигде не может быть получена в противном случае.
    Я попытался использовать значение "HEAD", но, по-видимому, он еще не обновлен в момент запуска "smudge", поэтому файлы заканчиваются датой "предыдущей" фиксации, а не фиксацией. > "Предыдущее" означает фиксацию, которая была проверена ранее. Проблема ухудшается, если другая ветка проверяется, так как файлы получают временную метку предыдущей ветки.

AFAIR, отсутствие информации в фильтре smudge было преднамеренным, чтобы препятствовать этому конкретному использованию механизма smudge/clean. Тем не менее, я думаю, что это может быть пересмотрено с учетом использования Петера: рабочее пространство "только для проверки" для немедленной публикации на веб-сервере.
В качестве альтернативы, любой, кто интересуется этим вариантом использования, может реализовать дополнительные аргументы smudge в качестве локального патча на сайте.

И тогда есть небольшие неприятности, которые кажутся неизбежными: если вы измените "чистый" фильтр и проведете более раннюю ревизию, он будет сообщаться как имеющий изменения (из-за изменения "чистого" определения).

Ответ 2

Так как в настоящее время существует опция %f, сценарии типа git-rcs-keywords могут выполнять задачу.

Это уже упоминалось в этом ответе.

gitattributes (5) manpage:

Sequence "%f" on the filter command line is replaced with
the name of the file the filter is working on. A filter 
might use this in keyword substitution. For example:

[filter "p4"]
    clean = git-p4-filter --clean %f
    smudge = git-p4-filter --smudge %f

Ответ 3

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

Если да, можете ли вы изменить свой процесс, чтобы файлы были извлечены в репозиторий git, а script выполнила проверку $URL$ или другого ключевого слова после. Таким образом, вы можете делать любые подстановки, которые вам нравятся, и ограничиваться только тем, что может быть определено script в выгруженном репозитории.

Ответ 4

Мы используем решение "канонического пути" в наших развертываниях (все они внутренние, FWIW).

Все программное обеспечение входит, например. /d/sw/xyz/a.c или D:\SW\xyz\a.c

Все URL-адреса для развернутых файлов отражают это, например, Http:.//host/d/sw/xyz/a.c

URL-адреса файлов репозитория начинаются с "sw", например. git://githost/gitrepo/xyz/a.c

Мы кодируем эти канонические пути в конфигурации (если это когда-либо понадобится изменить), и у нас есть скрипты /API, которые генерируют/ссылаются на URL-адреса "на лету" для динамического связывания между компонентами.