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

Question

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

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

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

Есть предложения?

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

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

Answer 1

Как упоминалось в "Есть ли в git что-то вроде svn propset svn:keywords или хуков до / после фиксации?" , Git не поддерживает расширение ключевых слов.

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

---

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

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

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

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

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

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

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

Answer 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

Answer 3

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

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

Answer 4

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

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

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

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

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