Bug Report: Creating a hardlink to any of the file in git repo cause the source file to show up in git commit message editor under "Changes not staged for commit" section.

 Creating a hardlink to any of the file in git repo cause the source 
 file
 to show up in git commit message editor under "Changes not staged for 
 commit"
 section.

 Reproduced on:
 Ubuntu 10.04, Gentoo, FreeBSD
 Git version: 1.7.6

 Bug has been observed by atleast 3 people.

 Follow these steps to reproduce:

 # create test repo
 cd /tmp
 mkdir -p test-repo/repo
 cd test-repo/repo
 git init
 git config user.name "Foo"
 git config user.email "foo@example.com"

 # put some files in the repo
 touch FILE1 FILE2 FILE3 FILE4 FILE5
 git add -A
 git commit -m "initial commit"

 # create git hook that hardlink FILE2 and FILE3 and remove the 
 hardlinks
 # right then and there
 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

 # make pre-commit executable
 chmod u+x .git/hooks/pre-commit

 # modify FILE1
 echo "hello world" >> FILE1

 # run git status
 git status
 -------------------------------------------------------------------------------
 # On branch master
 # Changes not staged for commit:
 #   (use "git add <file>..." to update what will be committed)
 #   (use "git checkout -- <file>..." to discard changes in working 
 directory)
 #
 #       modified:   FILE1
 #
 no changes added to commit (use "git add" and/or "git commit -a")
 -------------------------------------------------------------------------------

 # try commit using nano as commit editor and without usin -a flag
 VISUAL=nano git commit FILE1

 # Despite the fact that they are modified FILE2 and FILE3 will show in 
 the
 # commit message, under "Changes not staged for commit" section
 # like so:

 --------------------------------------------------------------------------------
 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # Explicit paths specified without -i nor -o; assuming --only paths...
 # On branch master
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #       modified:   FILE1
 #
 # Changes not staged for commit:
 #   (use "git add <file>..." to update what will be committed)
 #   (use "git checkout -- <file>..." to discard changes in working 
 directory)
 #
 #       modified:   FILE2
 #       modified:   FILE3
 #
 --------------------------------------------------------------------------------

 In case anyone interested, tor me this happens when I do a python EGG 
 build
 which hardlinks files in order to build.

 -- Michael

Michael <git-scm@webhippo.net> writes:

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.