It appears that "git commit <filename>" breaks the git precommit hook. Every other git command updates the index to make the commit-about-to-be-made before running the precommit hook, and indeed the 'pre-commit.sample' distributed with git assumes that the index reflects the commit. However, in the case of "git commit <filename>" the man page states "the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to git)". This seems like a bug. The precommit hook does not know (and has no apparent way of knowing) the contents of the commit-in-progress! If there is a workaround, it should be incorporated into the 'pre-commit.sample', which otherwise displays the same bug; to wit, you can inadvertently commit changes which would fail the pre-commit check by simply using the 'git commit <filename>' form. Worse/alternatively, bad files already existing in the index can block the commit of "good" files named on the command line. The fix appears clear: "git commit <filename>..." should do the equivalent of stashing the current index, adding the named files, *then* run the precommit hook, then do the commit, before restoring the stashed index. That would provide a consistent state for the precommit hook. --scott -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html