1

I'm moving from Jekyll to Hugo (awesome!).

My deployment hook has been working fine, but needed a minor update. The previous, and current flow is:

  • create a new temporary clone of the source (bare) repo on the same machine
  • run the generator
  • move the files to the web server directory
  • violà, new content

I wrote the shell script and when I execute it in the shell, on the sevrver, it works as expected! Yay!

However, when I make a trivial edit (to trigger the hook) and push, the hook runs, but I get errors from git. I've provided the most keenly odd output from set -x below:

remote: + rm -rf /home/sgharms/tmp/stevengharms.com
remote: + mkdir /home/sgharms/tmp/stevengharms.com
remote: + cd /home/sgharms/tmp/stevengharms.com
remote: + echo Changing into /home/sgharms/tmp/stevengharms.com
remote: Changing into /home/sgharms/tmp/stevengharms.com
remote: + cd /home/sgharms/tmp/stevengharms.com
remote: + git init
remote: Initialized empty Git repository in /home/sgharms/tmp/stevengharms.com/
remote: + git remote add origin file:////home/sgharms/stevengharms.com.git
remote: + git fetch origin
remote: From file:////home/sgharms/stevengharms.com
remote:  * [new branch]      master     -> origin/master
remote: + echo XXXXX
remote: XXXXX
remote: + pwd
remote: /home/sgharms/tmp/stevengharms.com
remote: + git checkout master
remote: fatal: This operation must be run in a work tree

But if I run the post-receive script with sh -x post-receive...

+ rm -rf /home/sgharms/tmp/stevengharms.com
+ mkdir /home/sgharms/tmp/stevengharms.com
+ cd /home/sgharms/tmp/stevengharms.com
+ echo Changing into /home/sgharms/tmp/stevengharms.com
Changing into /home/sgharms/tmp/stevengharms.com
+ cd /home/sgharms/tmp/stevengharms.com
+ git init
Initialized empty Git repository in /home/sgharms/tmp/stevengharms.com/.git/
+ git remote add origin file:////home/sgharms/stevengharms.com.git
+ git fetch origin
remote: Counting objects: 2304, done.
remote: Compressing objects: 100% (2222/2222), done.
remote: Total 2304 (delta 72), reused 2245 (delta 42)
Receiving objects: 100% (2304/2304), 118.65 MiB | 42.91 MiB/s, done.
Resolving deltas: 100% (72/72), done.
From file:////home/sgharms/stevengharms.com
 * [new branch]      master     -> origin/master
+ echo XXXXX
XXXXX
+ pwd
/home/sgharms/tmp/stevengharms.com
+ git checkout master
Branch master set up to track remote branch master from origin by rebasing.
+ ls .git
branches  config  description  FETCH_HEAD  HEAD  hooks  index  info  logs  objects  refs
...
...
+ git submodule update --init
Submodule 'themes/ananke' (https://github.com/budparr/gohugo-theme-ananke.git) registered for path 'themes/ananke'

OK. I have some useful data. But I'm not sure where to go from here.

  1. Is the problem the git submodule?
  2. whoami reports executing at the same user

I'm pretty stumped about what to do next to debug this. I've added all sorts of ls -al .git to make sure that the git stuff is always present, and it is. While I'm stymied, I'm also really curious as to what I'm missing here. Any takers?

  • 1
    A `post-receive` hook runs with environment variable `$GIT_DIR` set. This means Git won't *search* for the Git directory; it expects it to be wherever `$GIT_DIR` points right then. Usually, that's the issue with post-receive hooks. You can unset GIT_DIR or set it to the correct path or use `--git-dir` to override (any of these three will work). – torek Jul 30 '18 at 00:44
  • @torek: Thanks! That was the clue I needed to move forward. For future seekers: [Git Dir Not Working as Expected](https://stackoverflow.com/questions/1386291/git-git-dir-not-working-as-expected) was the other piece of the solution. – Steven Harms Jul 30 '18 at 15:10

1 Answers1

0

For future seekers, Torek's reply put me on the right path. Ultimately I updated the environment variables he pointed to like so:

GIT_DIR=$GIT_REPO # the bare-repository with the content in it `~/foo.git`
GIT_WORK_TREE=$TMP_GIT_CLONE # the "working" checkout of the bare repo
  • Note that if you allow Git to use the main index file (`$GIT_DIR/.index`) to index some other work-tree, be careful that you *only* use that index file to index that particular work-tree. Otherwise you will get other mysterious behaviors when Git thinks the work-tree contains something other than what it actually contains... – torek Jul 30 '18 at 15:15