Расширение Мерзавца информация о SHA1 в регистрацию без архивации?
Существует ли способ включать хеши фиксации мерзавца в файле каждый раз, я фиксирую? Я могу только узнать, как сделать это во время архивации, но я не смог узнать, как сделать это для каждой фиксации.
Я делаю научное программирование с мерзавцем как управление версиями, таким образом, этот вид функциональности был бы очень полезен по причинам воспроизводимости (т.е. сделайте, чтобы мерзавец хешировал автоматически включенный во все файлы результата и числа).
4 ответа
Вы можете легко поместить SHA-1 из файла (точнее, SHA-1 для blob-объекта, то есть SHA-1 содержимого файла), используя $ Id $ keywork и identity gitattribute .
Если вы хотите использовать SHA-1 для commit , готового решения нет, но вы можете использовать clean и smudge ] команды filter gitattribute . Обратите внимание, что это сильно повлияет на производительность, так как после фиксации каждый файл необходимо будет изменить, чтобы отразить новую сделанную фиксацию.
Хотя, как сказано в других ответах на этот вопрос, вам будет лучше встраивать номер версии в сгенерированные файлы при сборке, например, Ядро Linux и сам проект git делают это.
Грег объяснил в свой ответ , почему это невозможно
- Git - это контент VCS ( по сравнению с контролем версий или VCS )
- ключ SHA1 представляет контент
он не может быть частью контента
На самом деле, как упоминалось Якубом Наребски в его ответ , вы можете добавить SHA-1 самого большого двоичного объекта (содержимого) (см. атрибуты git )
Как упоминалось в вопросе « Чтобы поместить префикс?в коды Git / Svn », Git не имеет механизма « расширения ключевых слов » .
identКогда атрибут
identityустановлен для пути, git заменяет$ Id $в объекте blob на$ Id:, затем именем объекта большого двоичного объекта из 40 символов в шестнадцатеричном формате, за которым следует знак доллара$при оформлении заказа.
Любая последовательность байтов, которая начинается с$ Id:и заканчивается на$в файле рабочего дерева, при регистрации заменяется на$ Id $.
Это означает, что обычным обходным путем является какой-то процесс сборки , чтобы включить необходимую информацию в версионный, но отдельный файл .
В вашем случае файл со списком всех остальных файлов и их значением SHA1.
Такие файлы могут быть сгенерированы при каждой фиксации (например, при изменении только что состоявшейся фиксации).
В качестве примера отдельного файла Джефроми указывает на файл ВЕРСИЯ самого Git, созданный с помощью этого сценария
elif test -d .git -o -f .git &&
VN=$(git describe --match "v[0-9]*" --abbrev=4 HEAD 2>/dev/null) &&
case "$VN" in
*$LF*) (exit 1) ;;
v[0-9]*)
git update-index -q --refresh
test -z "$(git diff-index --name-only HEAD --)" ||
VN="$VN-dirty" ;;
esac
then
Включение хэша фиксации внутри файлов, включенных в фиксацию, обязательно приведет к изменению хеша. Чтобы обеспечить целостность репозитория с помощью механизма хеширования SHA1, Git не поддерживает (и не может) поддерживать такую функцию.
хеш git автоматически включается во все файлы результатов и рисунки.
Вы можете каким-то образом передать хэш в качестве входных данных в программу (например, как переменную среды).
Одно это еще не гарантирует, что вы передадите правильный хэш.
Возможно, вы можете написать сценарий, который извлекает конкретную фиксацию (по хешу или ссылке) в специальный (или временный) каталог, выполняет автоматическую сборку, затем запускает программу и передает хеш фиксации в качестве входных данных в программа.
Таким образом у вас будет больше уверенности в том, что вы получаете правильный хеш.
Но, тем не менее, кто-то может полностью передать любой поддельный хэш и создать вводящие в заблуждение цифры.