Git pre-commit hook works as a post-commit

The title pretty much says it all.

In the local repo I've got .git folder containing my hooks. I use my custom Lua source to write the current version in the file inside itself. Then in the pre-commit hook I have:

#!/bin/sh
#
# An example hook script to verify what is about to be committed.
# Called by "git commit" with no arguments.  The hook should
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.
#
# To enable this hook, rename this file to "pre-commit".

echo "START" >> E:/Desktop/tmp.txt

exec $LUA_HOME\\lua.exe ${PWD}\\hooks\\pre-commit.lua "${PWD}/lua/autorun/trackassembly_init.lua" "Rev." > E:/Desktop/tmp.txt

I've got two files. In the first I do the actual changes ( source file ). The second one I use to write the current version in ( version file ).

Whenever I use TortoiseGit and do:

1) Modify the source file
2) Repo Directory --> Right Click --> Git Commit "master"

The information about the source file is added in the indexes, but there is no trace of the changed version file with the new version inside it. This lead to a difference between the working copy and the version file and TortoiseGit puts a (!) on the directory.

According to the manual:

The pre-commit hook is run first, before you even type in a commit message. It’s used to inspect the snapshot that’s about to be committed, to see if you’ve forgotten something, to make sure tests run, or to examine whatever you need to inspect in the code. Exiting non-zero from this hook aborts the commit

Upvotes: 0

Views: 436

Answers (1)

choroba
choroba

Reputation: 241808

In git, you first stage a change (git add), then you commit it (git commit), (and then you push it, but it's not important here). The post-commit hook runs after the commit; if you change the working copy at that time, it doesn't influence the staged changes.

Upvotes: 1

Related Questions