Работа с расширением ключевых слов SVN с помощью git-svn
Недавно я спросил о расширении ключевых слов в 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: исполняемый файл"
Но это не кажется слишком сложным, чтобы эмулировать этот ключевой материал парой хуков фиксирования до / после коммита. Я первый человек, который хочет этого? У кого-нибудь есть код для этого?
4 ответа
Что здесь происходит: 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 потеряет большую часть своей скорости.
К сожалению, подстановка ключевых слов RCS нарушает это. Например, использование $Date$ потребовало бы, чтобы git checkout касался каждого файла в дереве при переключении веток.
Это неправда. $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 неверен. Он вставляет время / дату оформления заказа или что-то еще, что заставляет его работать.
Вот пример проекта, содержащий код конфигурации и фильтра, необходимый для добавления поддержки ключевых слов RCS в проект git:
https://github.com/turon/git-rcs-keywords
Это не так просто настроить, как хотелось бы, но, похоже, работает. Он использует пару фильтров smudge / clean, написанных на perl (аналогично описанному в ответе emk), и да, он затронет все файлы с расширениями, установленными в.gitattributes, как правило, немного замедляя работу.
Вы можете установить атрибут идент для ваших файлов, но это приведет к появлению таких строк, как
$Id: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef$
где deadbeef... это sha1 большого двоичного объекта, соответствующего этому файлу. Если вам действительно нужно это расширение ключевого слова, и оно вам нужно в git-репо (в отличие от экспортированного архива), я думаю, вам придется пойти с ident gitattribute с пользовательским скриптом, который делает расширение за вас. Проблема с использованием хука заключается в том, что файл в рабочем дереве не будет соответствовать индексу, и git подумает, что он был изменен.