7

I have this simple hook on /hooks/post-update inside a bare repository:

#!/bin/sh
git-update-server-info

GIT_WORK_TREE=/home/user/apps/application-site/dev git checkout -f develop
GIT_WORK_TREE=/home/user/apps/application-site/dev git submodule update --init

GIT_WORK_TREE=/home/user/apps/application-site/master git checkout -f master
GIT_WORK_TREE=/home/user/apps/application-site/master git submodule update --init

The repository has some submodules, that I am expecting is pushing to production server, and checkout the two branches on two directories, so can I have later a dev.myapp.com for the development branch and www.myapp.com for the master branch, and all this updating also the submodules on the branches.

Checkout is working as expected, but not the submodule update --init, :'(

The remote output raises this errors.

remote: Switched to branch 'develop'
remote: You need to run this command from the toplevel of the working tree.
remote: Switched to branch 'master'
remote: You need to run this command from the toplevel of the working tree.

I am not quite sure what to do.

Mario César
  • 3,699
  • 2
  • 27
  • 42

2 Answers2

8

The answer is to do exactly what git is telling you, which is:

remote: You need to run this command from the toplevel of the working tree.

So do that. Here's a sample post-update hook:

#!/bin/sh

export GIT_DIR=$(pwd)

cd /home/lars/projects/stackoverflow/gitstuff/worktree

git checkout -f master
git submodule init
git submodule update

This assumes that:

  • core.bare is false
  • receive.denyCurrentBranch is ignore. You need this because otherwise you'll get an error pushing into a repository with core.bare set to false.

...and seems to work in my limited testing.

larsks
  • 277,717
  • 41
  • 399
  • 399
  • 1
    Perfect ... just the repo is bare. "I have this simple hook on /hooks/post-update inside a bare repository" I am start thinking that is not possible using a bare repository – Mario César Sep 30 '11 at 21:24
  • But the repo *isn't* bare; you're defining a GIT_WORK_TREE. By definition a repository associated with a work tree is not a bare repository. Instead of setting GIT_WORK_TREE you could simple clone the base repository, which would put a `.git` directory in your work tree but would otherwise be a simpler solution. – larsks Oct 01 '11 at 00:14
2

Your first GIT_WORK_TREE variable (line 4) is suspect, considering you are refering in the next lines to a $WORK_TREE variable (which isn't defined in this script).


Note that starting git1.8.4 (July 2013), you wouldn't have (for git submodule commands) to go back to the root directory anymore.

See commit 091a6eb0feed820a43663ca63dc2bc0bb247bbae:

submodule: drop the top-level requirement

Use the new rev-parse --prefix option to process all paths given to the submodule command, dropping the requirement that it be run from the top-level of the repository.

Since the interpretation of a relative submodule URL depends on whether or not "remote.origin.url" is configured, explicitly block relative URLs in "git submodule add" when not at the top level of the working tree.

Signed-off-by: John Keeping

Depends on commit 12b9d32790b40bf3ea49134095619700191abf1f

This makes 'git rev-parse' behave as if it were invoked from the specified subdirectory of a repository, with the difference that any file paths which it prints are prefixed with the full path from the top of the working tree.

This is useful for shell scripts where we may want to cd to the top of the working tree but need to handle relative paths given by the user on the command line.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @MarioCésar now I am even more confused. You should have defined `WORK_TREE` (and then use it as you were in your script). But if you keep redefining `GIT_WORK_TREE`, you end up concatenating all those paths together, which isn't what you want to do. – VonC Sep 29 '11 at 09:02
  • So embarrassed, sorry @VonC This is not my script I am using, I don't realize that is not doing the same as my. Now is finally correct – Mario César Sep 30 '11 at 10:52
  • @Mario: ok ;) It is correct, but I supposed it still generates the errors you mentioned? – VonC Sep 30 '11 at 12:41