Eu sou novo no git, então peço desculpas (e por favor me corrija) se eu usar indevidamente a terminologia aqui, mas farei o meu melhor.

Estou tentando configurar um repositório git (hub) e uma cópia de trabalho do site de desenvolvimento (prime) em um servidor web. Tentei padronizá-lo após este artigo . Quero que a cópia de trabalho de desenvolvimento seja atualizada sempre que o repositório de hub for enviado. Tenho a impressão de que o gancho adequado para isso é post-update, que criei assim:

#!/bin/sh
whoami
cd /path/to/working-copy/
RET=`git pull`
echo $RET

Atualizar

Quando envio as alterações do meu repositório local para o hub vazio, recebo a seguinte saída do script pós-atualização:

remote: sites
remote: fatal: Not a git repository: '.'

No entanto, se eu usar o SSH no servidor como 'sites' do usuário e executar este script manualmente, ele funcionará muito bem. Alguma idéia do que pode estar errado com este gancho ou script?

Aqui está o roteiro que funcionou. Acho que a parte que faltava originalmente que o impedia de funcionar remotamente era ounset GIT_DIR

#!/bin/sh
cd /path/to/working-copy/ || exit
unset GIT_DIR
git pull repo branch

exec git-update-server-info

Em vez disso, tente:

#!/bin/sh
cd /path/to/working-copy/
env -i git pull

Apesar de que GIT_DIR não definido simplesmente funciona.

o problema ocorre quando você define GIT_DIR incorretamente em outro lugar.

você pode simplesmente adicionar isso: GIT_DIR = .git / Vai funcionar

No meu caso, eu tinha especificado uma árvore de trabalho, e isso quebra em alguns comandos, como pull(ou mais precisamente fetch).

Para remover a configuração da árvore de trabalho se ela estiver em sua configuração git, use:

git config --unset core.worktree

(Existem outras maneiras de definir uma árvore de trabalho)

Importante observar,

Não há quase nenhuma mudança neste ser seu problema, a menos que você mesmo tenha cavado esse buraco ao seu redor usando uma árvore de trabalho personalizada em primeiro lugar.

Brincadeira:

Isso implica para mim que os internos do git usam caminhos relativos à worktree + .git/em alguns casos. Na minha experiência, as árvores de trabalho não são bem suportadas, exceto pelas partes mais fundamentais do git. Eu não experimentei completamente, o Git provavelmente se comportaria se eu definir qualquer que seja a variável de configuração do diretório git corretamente, com a qual eu não brinquei.

Você provavelmente tem um problema de permissão. Não tenho certeza de como você configurou seu repositório git, mas se ele estiver sendo executado sob o gitusuário, certifique-se de que o gitusuário tem permissão para executar o git pullno diretório do projeto.

Opcionalmente, tente isso para descobrir qual usuário você é quando o gancho é executado:

echo `whoami`