Работа с расширением ключевых слов SVN с помощью git-svn

Question

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

Что бы там ни было, для проекта, над которым я сейчас работаю, требуется расширение ключевых слов SVN, например:

svn propset svn:keywords "Id" expl3.dtx

, чтобы поддерживать эту строку в актуальном состоянии:

$Id: expl3.dtx 803 2008-09-11 14:01:58Z will $

Но я бы очень хотел использовать Git для контроля версий. К сожалению, git-svn не поддерживает это, согласно документации:

«Мы игнорируем все свойства SVN, кроме svn: исполняемый файл»

Но это не кажется слишком сложным, чтобы эмулировать этот ключевой материал парой хуков фиксирования до / после коммита. Я первый человек, который хочет этого? У кого-нибудь есть код для этого?

Answer 1

Что здесь происходит: Git оптимизирован для быстрого переключения между ветками. В частности, git checkout разработан так, чтобы не трогать файлы, идентичные в обеих ветвях.

К сожалению, подстановка ключевых слов RCS нарушает это. Например, использование $Date$ потребует git checkout для прикосновения к каждому файлу в дереве при переключении ветвей. Для хранилища размером с ядро ​​Linux это приведет к полной остановке.

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

$ git tag v0.5.whatever

... и затем вызовите следующую команду из вашего Makefile:

$ git describe --tags
v0.5.15.1-6-g61cde1d

Здесь git сообщает мне, что я работаю над анонимной версией 6 коммитов после v0.5.15.1, с хешем SHA1, начинающимся с g61cde1d. Если вы поместите вывод этой команды в файл *.h где-нибудь, вы в деле, и у вас не будет проблем со связыванием выпущенного программного обеспечения с исходным кодом. Это предпочтительный способ ведения дел.

Если вы не можете избежать использования ключевых слов RCS, вы можете начать с этого объяснения Ларса Хемли . В принципе, $Id$ довольно просто, и если вы используете git archive, вы также можете использовать $Format$.

Но, если вы абсолютно не можете избежать ключевых слов RCS, вам следует начать:

git config filter.rcs-keyword.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
git config filter.rcs-keyword.smudge 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date: `date`\\\$/"'

echo '$Date$' > test.html
echo 'test.html filter=rcs-keyword' >> .gitattributes
git add test.html .gitattributes
git commit -m "Experimental RCS keyword support for git"

rm test.html
git checkout test.html
cat test.html

В моей системе я получаю:

$Date: Tue Sep 16 10:15:02 EDT 2008$

Если у вас возникли проблемы с выходом оболочки из команд smudge и clean, просто напишите собственные сценарии Perl для расширения и удаления ключевых слов RCS соответственно и используйте эти сценарии в качестве фильтра.

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

Answer 2

К сожалению, ключевое слово RCS замена нарушает это. Например, использование $ Date $ потребует git Оформить заказ, чтобы коснуться каждого файла в дерево при переключении веток.

Это не правда. $ Date $ и т. Д. Расширяется до значения, которое сохраняется во время регистрации. Это гораздо полезнее в любом случае. Так что это не изменится на других ревизиях или ветвях, если файл фактически не повторно проверен в. Из руководства RCS:

   $Date$ The  date  and  time the revision was checked in.  With -zzone a
          numeric time zone offset is appended;  otherwise,  the  date  is
          UTC.

Это также означает, что предложенный выше ответ с фильтром rcs-keyword.smudge неверен. Он вставляет время / дату извлечения или что-то, что заставляет его работать.

Answer 3

Вот пример проекта, содержащий код конфигурации и фильтра, необходимый для добавления поддержки ключевых слов RCS в проект git:

https://github.com/turon/git-rcs-keywords

Это не так просто настроить, как хотелось бы, но, похоже, работает. Он использует пару фильтров smudge / clean, написанных на perl (аналогично описанному в ответе emk), и да, он затронет все файлы с расширениями, установленными в .gitattributes, как правило, немного замедляя работу.

Answer 4

Вы можете установить атрибут идент для ваших файлов, но это приведет к появлению строк вроде

$Id: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef$

где deadbeef... - это sha1 большого двоичного объекта, соответствующего этому файлу. Если вам действительно нужно это расширение ключевого слова, и оно вам нужно в git-репо (в отличие от экспортируемого архива), я думаю, вам придется использовать атрибут ident gitattribute с пользовательским сценарием, который выполняет расширение для вы. Проблема только с использованием ловушки заключается в том, что файл в рабочем дереве не будет соответствовать индексу, и git подумает, что он был изменен.