4

After editing my old question a few times, I make a new one because it is a new question now.

In .git/hooks/post-update I have:

echo "a" >> /home/pi/log git update-server-info git stash git merge testing >> /home/pi/log 

To make an automated checkout. So I run on the client:

git push testing HEAD:testing 

Now my /home/pi/log contains:

a Updating ae2f44b..04753a9 Fast-forward application/views/main/index.php | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 

But the file did not change!

$ git merge testing Already up-to-date. 

If I remove the script, make the push and run git stash, git merge testing it works.

Update

For testing I changed a number in a file from 17 to 20. I can see the right file version if I run

git show application/views/main/index.php 

but

vim application/views/main/index.php 

Still contains the old number. But git claims the file is updated:

$ git merge testing Already up-to-date. 
1
  • Can you check the environment variables GIT_DIR, GIT_WORK_TREE and GIT_INDEX in the script's execution context? Commented Feb 10, 2012 at 16:01

3 Answers 3

5

EDIT

It looks like this is your problem:

 pre-receive update post-receive post-update 

These hooks can be run either in a bare or a non-bare repository. In both cases, the current working directory will be the git directory. So, if this is a bare repository called "/src/git/test.git/", that will be the current working directory -- if this is a non-bare repository and the top level of the working tree is "/home/mark/test/" then the current working directory will be "/home/mark/test/.git/".

In both cases, the following environment variable is set: GIT_DIR is set to ‘.’

With a working tree, this is unexpectedly awkward, as described in Chris Johnsen’s answer that I linked to earlier. If only GIT_DIR is set then this comment from the git man page applies:

Note: If --git-dir or GIT_DIR are specified but none of --work-tree, GIT_WORK_TREE and core.worktree is specified, the current working directory is regarded as the top directory of your working tree.

In other words, your working tree will also be the current directory (the ".git" directory), which almost certainly isn’t what you want.

You could try setting GIT_WORK_TREE=.. or GIT_WORK_TREE="$GIT_DIR/.." inside the hook


But the file did not change!

Most likely it did. Perhaps only the lineending did, or there were whitespace changes that are ignored when viewing the diffs, but it did change. Git knows, because the SHA1 sum of the file content changed.

Are you using windows on either end?

Windows has a tendency to mess with the line-endings. See the core.autocrlf and related options:

Sign up to request clarification or add additional context in comments.

5 Comments

Yes, the client is on windows. How can this be an issue here? Why does it work manually but not with the script?
I am counting up a number in a file. 17 must be different from 20 regardless some line endings or whitespaces. Doesn't it?
It is always PEBCAK! I ask because I don't see how your answer is related to the question. I don't have trouble with line endings and even if there where all messed up it would no explain why I commit the string "20" and the updated file on the server contains "17".
Added relevant info to the answer
I think that must be it but I did not get it to work. In the other post-update script they use export GIT_DIR=$(cd $GIT_DIR; pwd) and GIT_WORK_TREE=${GIT_WORK_TREE-..} but that did not work either. I don't have the time to play around with git right now. But I will try this again in a few days...
2

The solution is to use post-receive as Alex pointed out. Also you need run unset GIT_DIR at the top of your script.

On the server I have created a second branch and switched to it:

$ git branch master * testing 

My .git/hooks/post-receive now looks like this:

unset GIT_DIR cd .. git merge master 

On the client I run git push.

Comments

1

Did you try to use the post-receive hook instead? Maybe something is not yet finished in the post-update and that is why the merge is not working.

Also I think you should try to include git reset --hard in the script so that the git status is synchronised with the file system.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.