Работа с расширением ключевого слова 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 будет считать, что он был изменен.