Использование skip-worktree для файла, который изменяется с помощью git hooks?

Question

У меня есть ловушка post-commit, которая редактирует указанный исходный файл c (в частности, записывает commit ha sh в строку в классе c#). Сценарий:

#!/bin/sh
hashStr=`git log --pretty=format:'%H' -n 1`
str="public static class GitHash { public static readonly string CommitHash = \"$hashStr\"; }"
echo $str > MyApp\\MyNamespace\\gitHash.cs

Этот же сценарий есть в моих перебазах после слияния и т.д. c. Он работал нормально и показывался измененным в git, пока я не добавил файл GitHa sh .cs в skip-worktree:

git update-index --skip-worktree MyApp/MyNamespace/GitHash.cs

Теперь файл не изменяется и остается в состоянии это было, когда я добавил его в skip-worktree. Если я удаляю его из skip-worktree, ловушка снова работает (файл изменен). Если я правильно понимаю skip-worktree, то можно использовать его, когда я хочу изменить файлы локально, но не хочу случайно их фиксировать и не хочу видеть эти файлы, когда я выполняю git diff. Однако, похоже, что каким-то образом он блокирует хук от редактирования этого файла?

Итак, если я хочу, чтобы файл был изменен хуками И не отображался на git diff, что мне делать?

Answer 1

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

Зачем вообще хранить файл в системе контроля версий, если это чисто сгенерированный файл? Если вы удалите его из коммита (и, возможно, в .gitignore) и сделаете его генерацию частью процесса сборки, а не хуком, тогда вы должны получить описываемые вами поведения.

Answer 2

Технически, бит skip-worktree существует в качестве помощника для разреженной проверки. Использование его таким, какой вы есть, является злоупотреблением. Однако другой бит, assume-unchanged, является помощником для медленных системных вызовов lstat, и хотя вы можете использовать его таким же образом, это также техническое нарушение. Так что вам в любом случае не повезло.

Обычно лучше вообще этого не делать, если это вообще возможно. Например, если ваша система сборки может просто создать соответствующую информацию - записать ее в файл, который никогда не будет зафиксирован - обычно это путь к go. (Это то, что Марк Адельсбергер сказал .) Тем не менее, вы можете настроить хук после фиксации для записи в файл, но при этом установить один или оба этих бита, что вы и делаете. Это просто означает, что файл не go в новый коммит: вместо этого индекс висит на старой копии этого файла.

Чтобы получить обновленный файл в новый коммит, вы должны скопировать файл в Git index до того, как вы сделаете новый коммит. Но помните, что каждый ваш коммит имеет новый уникальный идентификатор ha sh. Это означает, что вы должны сохранить идентификатор ha sh, прежде чем его узнаете.

Другими словами, идентификатор ha sh, который вы можете сохранить в файле, который передается, никогда не будет идентификатором ha sh коммит, который вы можете сделать, который содержит этот файл. Вы можете получить тот прямо перед этим. Возможно, этого достаточно: вы можете до сделать коммит, сохранить идентификатор ha sh текущего коммита, убедившись, что он совпадает со всем, кроме new-ha sh -ID-файл:

bit=skip-worktree
# or assume-unchanged: either will work, though both are technically abuse

git commit                    # make sure we commit what we have
hash=$(git rev-parse HEAD)    # get the hash ID of the current commit
echo "built from stuff that mostly matches $hash" > file.ext
git update-index --no-$bit file.ext
git add file.ext
git update-index --$bit file.ext
git commit -m "update build info"

Но вы определенно не можете сохранить идентификатор ha sh коммита с правильным идентификатором ha sh в файле, потому что вы не можете предсказать, что это будет: сохранение будущего идентификатора ha sh в файле изменяет идентификатор ha sh будущего коммита. ¹

---

¹ Единственное возможное исключение здесь, если вам удастся найти фиксированную точку в функции ha sh.