Question

Change your .git/hooks/pre-commit to the following:

#!/bin/bash
git status
sleep 10000

Change some file, but do not stage it with git add. Then run git commit -a.

You should see something like:

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   somefile.txt

And then it will wait on the sleep call. In the meantime, open up another shell window and run git status. You should see:

# 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:   somefile.txt

The different git calls are seeing a different index, with pre-commit hook seeing the index as it is about to be committed according to whether commit was invoked with -a/--all or not, but the same git commands in other shells are not affected.

My problem is I have a script that sees the index as if git were running in another shell when it's installed as the pre-commit hook, instead of seeing the index that pre-commit hooks are supposed to see. I would like to get it to see the 'pre-commit index', or at least understand how it works that the index looks different in different shells.

The script does something (with vagrant) wherein it would not be seen as having the same parent PID or environment, and perhaps that's related.


update: Possibly has something to do with index vs index.lock?

Était-ce utile?

La solution

The git commit -a will modify the index, and can be rejected. It seems to me that before the command completes, its not-yet-validated index modifications can't be shown to any other executing command. My first try at convincing git you're running as part of the hook and not as part of some other executing command would be to export every variable starting with GIT_ (export ${!GIT_*}).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top