# precommit hook broken with "git commit <filename>"

3 messages from 2011-04-12 to 2011-04-12. Participants: C. Scott Ananian, Junio C Hamano.
Thread: https://gitlist.dev/t/27073

## C. Scott Ananian, 2011-04-12 15:17

Subject: precommit hook broken with "git commit <filename>"
Message-ID: <BANLkTimB=TZ1gP-18ywbZUOZSbDamkRwCg@mail.gmail.com>
URL: https://gitlist.dev/e/BANLkTimB%3DTZ1gP-18ywbZUOZSbDamkRwCg%40mail.gmail.com

```
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, 2011-04-12 21:04

Subject: Re: precommit hook broken with "git commit <filename>"
Message-ID: <7vvcyjnpvj.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vvcyjnpvj.fsf%40alter.siamese.dyndns.org
In-Reply-To: <BANLkTimB=TZ1gP-18ywbZUOZSbDamkRwCg@mail.gmail.com>

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

```

## C. Scott Ananian, 2011-04-12 23:09

Subject: Re: precommit hook broken with "git commit <filename>"
Message-ID: <BANLkTimm0CBP_vX1ZFoyLa7QR5qgnCgZKw@mail.gmail.com>
URL: https://gitlist.dev/e/BANLkTimm0CBP_vX1ZFoyLa7QR5qgnCgZKw%40mail.gmail.com
In-Reply-To: <7vvcyjnpvj.fsf@alter.siamese.dyndns.org>

```
On Tue, Apr 12, 2011 at 5:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "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

```