Hi, Following up to a recent thread: http://lists.zerezo.com/git/msg419909.html I wrote a (very primitive) update hook that updates the working tree on the remote side when pushing to its current branch. ==== cut here : .git/hooks/update ==== #!/bin/bash if [[ "$1" = $(git symbolic-ref HEAD) ]]; then GIT_DIR=$(pwd) cd .. git reset --soft $2 git merge $3 git reset --soft $2 fi ==== end ==== It has several problems. First, the GIT_DIR=$(pwd) cd .. is ugly. Indeed, since I push to the URL of the tree of the remote repository, git knows about the location of this tree, but it doesn't seem to tell it to the update hook. So, I hardcoded ".." here. And the GIT_DIR the hook receives isn't terribly informative, it's just ".", and having a relative path here means I have to do this GIT_DIR=$(pwd) before doing any "cd". Then, git reset --soft $2 git merge $3 does the update (there should also be something to complain loudly if there is a risk of conflict here, but let's say it's on the todo-list). But then, the refs/heads/<branch> does not point anymore to the point where git expects it. So, I need another git reset --soft $2 to get back to the point it used to be. I find that pretty ugly too :-(. I really think there should be something about this in git itself. Not necessarily something to actually update the tree, but at least, make it easy to actually "update" the tree after a push. In mercurial, for example, the above hook is just: [hooks] changegroup = hg update in .hg/hgrc. It tells hg to run "update" each time a group of changes is pushed into the repository. And update _knows_ which revision the tree used to point to, and which revision is the head of the branch. Any opinion? Thanks, (at the moment, I need this to easily push changes to a machine to make them available to users, letting them the choice between git and rsync to get a fresh tree. Most of the users won't have git and won't want to learn it) -- Matthieu - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html