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