threads / discuss / 27073

precommit hook broken with "git commit <filename>"

Subject: precommit hook broken with "git commit <filename>"

## tl;dr

3 messages between Apr 12, 2011 and Apr 12, 2011.

replies: 2people: 2as markdown or json

C. Scott Ananian· Apr 12, 2011, 15:17 UTC · lore

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

Junio C Hamano· Apr 12, 2011, 21:04 UTC · re: C. Scott Ananian · lore

Re: precommit hook broken with "git commit <filename>"

"C. Scott Ananian" <cscott@laptop.org> writes:

Show 8 quoted lines

> 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)".

Doesn't the command call the pre-commit hook with GIT_INDEX_FILE environment set to the temporary index used to create the (partial) commit? The sample pre-commit hook runs "diff --cached" between that index and HEAD (or the empty tree), and should show the change about to be committed.

C. Scott Ananian· Apr 12, 2011, 23:09 UTC · re: Junio C Hamano · lore

Re: precommit hook broken with "git commit <filename>"

On Tue, Apr 12, 2011 at 5:04 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> "C. Scott Ananian" <cscott@laptop.org> writes:
>
>> 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)".
>
> Doesn't the command call the pre-commit hook with GIT_INDEX_FILE
> environment set to the temporary index used to create the (partial)
> commit?  The sample pre-commit hook runs "diff --cached" between that
> index and HEAD (or the empty tree), and should show the change about to be
> committed.

Thanks for the quick answer. You're right, of course. Our tests were subtly broken. Now that we understand how it's supposed to work, everything looks fine.

Great work on git, btw.  Yet another case where something I think
might be broken turns out to be working correctly (and smartly) all
along, or was recently fixed, etc...
 --scott