Есть ли в git что-то вроде `svn propset svn: keys` или до / после фиксации хуков?
-
09-06-2019 - |
Вопрос
Просматривая документацию по 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 $
постоянно обновляется с соответствующей информацией всякий раз, когда происходит фиксация.
Решение
Цитирование из FAQ Git :
Есть ли в git расширение ключевых слов?
Не рекомендуется. Расширение ключевого слова вызывает все виды странных проблем и в любом случае не очень полезно, особенно в контексте SCM. за пределами Git вы можете выполнить расширение ключевых слов с помощью сценария. Экспорт ядра Linux скрипт делает это для установки переменной EXTRA_VERSION в Makefile.
Смотрите gitattributes (5), если вы действительно хотите это сделать. Если ваш перевод не обратимым (например, расширение ключевого слова SCCS), это может быть проблематично.
Другие советы
Я написал довольно полный ответ к этому в другом месте, с кодом, показывающим, как это сделать. Резюме:
<Ол> git description
является разумной альтернативой. $ Id $
и $ Format $
довольно просто. gitattributes
и пользовательского фильтра. Я предоставляю пример реализации $ Date $
. Решения, основанные на хуках, обычно бесполезны, потому что они загрязняют вашу рабочую копию.
Git имеет хуки pre-commit и post-commit, они находятся внутри каждого каталога .git / hooks. Просто измените файлы и выполните команду chmod, чтобы сделать их исполняемыми.
Пожалуй, наиболее распространенное свойство SVN, svn: ignore, выполняется через файл .gitignore, а не через метаданные. Боюсь, у меня нет ничего более полезного для других видов метаданных.
Несмотря на вековую Q & A. Я думал, что добавлю один, так как это долго мучало меня.
Я привык перечислять файлы в каталоге в обратном порядке (забавно, а?). Причина в том, что я хотел бы видеть, какие файлы, которые у меня (или кто-то еще) изменился недавно.
Git испортит мои планы, потому что при переключении ветки локальное хранилище полностью перезаписывает отслеживаемые файлы из (инкрементных ... я знаю ...) копий, которые находятся в упакованном локальном хранилище.
Таким образом, все извлеченные файлы будут иметь отметку времени оформления и не будут отражать время их последнего изменения ..... Как это раздражает.
Итак, я разработал однострочную версию в bash, которая будет обновлять свойство $ Date: $ внутри любого файла ВРЕМЯ ПОСЛЕДНЕЙ МОДИФИКАЦИИ В СООТВЕТСТВИИ С НАСТОЯЩИМ ФАЙЛОМ У меня будет немедленное сообщение о состоянии последней модификации без необходимости просматривать git log
, git show
или любой другой инструмент, который дает время фиксации в blame mode.
Следующая процедура изменит ключевое слово $ 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