precommit hook broken with "git commit <filename>"

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