Michael [off-list ref] writes:
echo "ln -vf FILE2 ../HARDLINK_TO_FILE2" >| .git/hooks/pre-commit
echo "rm -vf ../HARDLINK_TO_FILE2" >> .git/hooks/pre-commit
echo "ln -vf FILE3 ../HARDLINK_TO_FILE3" >> .git/hooks/pre-commit
echo "rm -vf ../HARDLINK_TO_FILE3" >> .git/hooks/pre-commit
This does not have to do anything with hardlink. A simple "touch" should
do as long as FILE2/FILE3 are sufficiently old.
You are smudging cached stat information in your pre-commit hook (st_ctime
would be different), and that is shown as a difference between the working
tree and the index (note that nowhere in githooks documentation we say
pre-commit hook is allowed to muck with the working tree files). I think
we do refresh the cached stat information before running the pre-commit
hook so that the hook can check the list of working tree files that are
different from the index using diff-files, but the purpose of the said
hook is to validate, and not affect, the state of the working tree, and I
wouldn't be surprised if we do not update the cached stat information
after the hook returns control to us.
If you really want to munge the working tree inside pre-commit, I think
adding "git update-index --refresh" at the end of pre-commit hook would
make the phantom change go away.