Есть ли в git что-нибудь вроде `svn propset svn: keywords` или хуков до / после фиксации?

Просматривая документацию по git, я не вижу ничего аналогичного крючкам фиксации SVN или функциям "propset", которые могут, скажем, обновлять номер версии или уведомление об авторских правах в файле всякий раз, когда он фиксируется в репозитории.

Ожидается ли, что пользователи git будут писать внешние скрипты для такого рода функций (что, кажется, не исключено), или я просто пропустил что-то очевидное?

Изменить: для ясности, меня больше интересует, например,

svn propset svn:keywords "Author Date Id Revision" expl3.dtx

где строка вроде этой:

$Id: expl3.dtx 780 2008-08-30 12:32:34Z morten $

обновляется с соответствующей информацией всякий раз, когда происходит фиксация.


person Will Robertson    schedule 02.09.2008    source источник


Ответы (5)


Цитата из Git FAQ:

Есть ли в git расширение ключевых слов?

Не рекомендуется. Расширение ключевых слов вызывает всевозможные странные проблемы и в любом случае бесполезно, особенно в контексте SCM. Вне git вы можете выполнить расширение ключевых слов с помощью скрипта. Сценарий экспорта ядра Linux делает это, чтобы установить переменную EXTRA_VERSION в Makefile.

См. Gitattributes (5), если вы действительно хотите это сделать. Если ваш перевод необратим (например, расширение ключевого слова SCCS), это может быть проблемой.

person Jordi Bunster    schedule 02.09.2008
comment
Я обнаружил, что это довольно хорошо работает с проектами git: github.com/turon/git-rcs- ключевые слова - person Mark; 20.02.2013
comment
@PA Если бесплатный ответ вам не подходит, не обращайте на него внимания. По приведенным здесь ссылкам достаточно легко найти лучшее объяснение. Жалобы также не помогают вам обрести знания. И называется он Git, а не GIT. - person Micha Wiedenmann; 09.10.2015
comment
Спасибо за указатель на FAQ по Git. Я нашел эту цитату забавной: расширение ключевых слов ... в любом случае бесполезно. Как разработчик службы поддержки я ежедневно обращаюсь к атрибутам исходного кода. Например, хранимые процедуры нашей базы данных находятся в системе контроля версий с атрибутами ревизии вверху. Я могу использовать атрибут ревизии, чтобы проверить, какая версия хранимой процедуры установлена ​​в базе данных. - person Paul Williams; 21.12.2016

Я написал довольно полный ответ на это в другом месте. , с кодом, показывающим, как это сделать. Резюме:

  1. Вы, вероятно, не захотите этого делать. Использование git describe - разумная альтернатива.
  2. Если вам действительно нужно это сделать, $Id$ и $Format$ сделать довольно просто.
  3. Для чего-то более сложного потребуется использовать gitattributes и настраиваемый фильтр. Я привожу пример реализации $Date$.

Решения, основанные на функциях перехвата, обычно бесполезны, потому что они загрязняют вашу рабочую копию.

person emk    schedule 17.09.2008

В Git есть хуки до и после фиксации, они расположены внутри каждого каталога .git / hooks. Просто измените файлы и измените их chmod, чтобы сделать их исполняемыми.

person georg    schedule 02.09.2008

Хотя извечный Q&A. Я подумал, что брошу одну, так как это уже давно меня беспокоит.

Я привык перечислять файлы в каталоге в обратном порядке (смешно, а?). Причина в том, что я хотел бы увидеть, какие файлы я (или кто-то еще) изменил в последнее время.

Git испортит мои планы, потому что при переключении ветки локальное репо полностью перезапишет отслеживаемые файлы из (инкрементальных ... я знаю ...) копий, которые находятся в упакованном локальном репо.

Таким образом, все файлы, которые были извлечены, будут иметь отметку времени извлечения и не будут отражать время их последнего изменения ..... Как это раздражает.

Итак, я разработал однострочник в bash, который обновит свойство $ Date: $ внутри любого файла ВРЕМЯ ПОСЛЕДНЕЙ МОДИФИКАЦИИ В СООТВЕТСТВИИ С ФАЙЛОВОЙ СИСТЕМОЙ, так что у меня будет немедленное сообщение о состоянии последней модификации без необходимости просматривать git log, git show или любой другой инструмент, который показывает время фиксации в режиме виноват.

Следующая процедура изменит ключевое слово $ Date: $ только в отслеживаемых файлах, которые будут зафиксированы в репо. Он использует git diff --name-only, который перечисляет файлы, которые были изменены, и ничего больше ....

Я использую этот однострочный файл вручную перед фиксацией кода. Одна вещь, однако, заключается в том, что я должен перейти в корневой каталог репо, прежде чем применять это.

Вот вариант кода для Linux (вставлен многострочным для удобства чтения)

git diff --name-only | xargs stat -c "%n %Y" 2>/dev/null | \
perl -pe 's/[^[:ascii:]]//g;' | while read l; do \
   set -- $l; f=$1;  shift; d=$*; modif=`date -d "@$d"`; \
   perl -i.bak -pe 's/\$Date: [\w \d\/:,.)(+-]*\$/\$Date: '"$modif"'\$/i' $f; \
   git add $f; done

и OSX

git diff --name-only | xargs stat -f "%N %Sm" | while read l; do \
   set -- $l; f=$1; shift; d=$*; modif=`date -j -f "%b %d %T %Y" "$d"`; \
   perl -i.bak -pe 's/\$Date: [\w \d\/:,.)(+-]*\$/\$Date: '"$modif"'\$/i' $f; \
   git add $f; done
person superk    schedule 23.01.2017

Возможно, наиболее распространенное свойство SVN, svn: ignore, реализуется через файл .gitignore, а не через метаданные. Боюсь, у меня нет ничего более полезного для других типов метаданных.

person James A. Rosen    schedule 02.09.2008