git post-receive hook не может перейти обратно в исходный cwd - PullRequest
8 голосов
/ 12 июля 2011

При отправке в наш общий пустой репозиторий (поверх ssh), post-commit не работает должным образом.
Это довольно часто встречается, как я обнаружил во многих потоках, и отлично работает для двух других репозиториев в том жесервер, который сводит меня с ума.

#!/bin/sh
GIT_WORK_TREE=/ab/cd/staging git checkout -f

Сам репозиторий находится в том же каталоге, что и каталог, который хук должен установить на

/ab/cd/barerepo

При нажатии он не проверяетфайлы по указанному пути, но выдает это сообщение об ошибке:

Writing objects: 100% (3/3), 299 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
fatal: Could not jump back into original cwd
error: hooks/post-receive exited with error code 128

Я не смог найти никакой информации о том, что это значит.(Насколько я могу судить, Google вызывает только коммиты из вклада в сам git).Поэтому я прочитал, угадал и попробовал…

  • дополнительно установив GIT_DIR в ловушку после получения
  • , повторно инициализируя голое репо с помощью --git-dir = / ab / cd / barerepo --working-dir = / ab / cd / staging
  • установка рабочего каталога вручную в barerepo / config
  • настройка пустой репо и фиксация
  • настройка пустойрепо путем клонирования

Прямо сейчас конфиг выглядит так

[core]
     repositoryformatversion = 0
     filemode = true
     bare = true

но у меня тоже было (без усилий)

[core]
    repositoryformatversion = 0
    filemode = true
    bare = true
    sharedrepository = 1
    worktree = /ab/cd/staging
    logallrefupdates = true
[receive]
    denyNonFastforwards = true

Я также добавилвторая строка для ловушки после получения

echo "post-receive done" > updated.txt

Записывает файл в каталог пустого хранилища.Это имеет смысл для меня, так как GIT_DIR, кажется, установлен на «.», Что подтверждается перехваченным пост-получением, полученным мной от другого SO вопроса

echo Running $BASH_SOURCE
set | egrep GIT
echo PWD is $PWD

Результат:

Running hooks/post-receive
GIT_DIR=.
PWD is /ab/cd/barerepo

Так как я могу заставить git вернуться к исходному cwd (текущему рабочему каталогу?)?К вашему сведению: я все еще довольно новичок в мерзавцах, и у меня возникает глупое ощущение, что я упускаю что-то очевидное, но не могу найти ничего существенного в этом конкретном сообщении об ошибке, и это заставляет меня задуматься.Сам толчок работает нормально, кстати.

Ответы [ 3 ]

18 голосов
/ 15 декабря 2011

Я также столкнулся с этой проблемой для одного сайта из десяти, размещенного на том же сервере.

У каждого сайта есть чистое репо на веб-сервере (не доступном для Интернета), к которому обращаются наши разработчики. Как и вы, мы используем перехват git post-receive, чтобы затем GIT_WORK_TREE=/whatever/livesite git checkout -f в каталог, содержащий фактический корневой каталог веб-сервера.

Изучая, что отличалось от того, что не удалось с fatal: Could not jump back into original cwd, я увидел, что во всех рабочих случаях имена репозитория были такими:

/var/www/coolsite.com.git   <-- bare repo
/var/www/coolsite.com.live  <-- checked out from hook; contains site root in public subdir

Ошибка выглядела так:

/var/www/brokensite.com.git  <-- bare repo
/var/www/brokensite.com      <-- checked out from hook; contains site root in public subdir

Таким образом, наличие живой копии получило имя, подобное тому, что git выдал эту ошибку. Изменение имени репозитория рабочей копии живого сайта на «.wtf» решило проблему (в конце концов я просто использовал «.live», как и другие).

В моем случае серверная версия Git - 1.6.1, а все машины для разработки - 1.7.5.4.

Так что название голого репо и живого репо, похоже, оказывает влияние. Не уверен, является ли это ошибкой в ​​git или просто побочным эффектом магической эквивалентности 'foo' и 'foo.git.

7 голосов
/ 03 августа 2011

По моему опыту, ваша проблема заключается в том, что у вас есть хранилище .git и каталог вашего рабочего дерева (в который проверяется хук после получения) в одном каталоге: ab / cd.

Я также новичок в GIT, и этот пост мне очень помог, так что спасибо!Удалив все исправления, которые вы уже попробовали, я наткнулся где-то на пост (боюсь, я не могу его сейчас найти), в котором читается репозиторий .git, а каталог с рабочим деревом не может находиться в одном каталоге.

Я не знаю, почему.

Например, у вас есть каталог / staging / в вашем / var / www.Это будет означать, что вы должны поместить свой пустой .git-репозиторий в / var / GIT (или что-то в этом роде), а не /var/www.

Другая проблема, с которой я столкнулся, была с разрешениями, поэтому я chown'ed и chmod'ed обакаталоги, чтобы гарантировать, что удаленный пользователь, с которым я нажимал, имел разрешение на чтение / запись в оба каталога.

Во всяком случае, я сделал это, и я получил от вас, где вы были к этому:

Counting objects: 3357, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2848/2848), done.
Writing objects: 100% (3057/3057), 15.20 MiB | 4.70 MiB/s, done.
Total 3057 (delta 1536), reused 0 (delta 0)
Checking out files: 100% (3720/3720), done.
To ssh://xxxxxx@xxxxxxxxxxxxxxx/var/GIT/project.git
   945fe94..dbe1f0b  master -> master

Это и хороший толстый каталог проверки, полный кода:)

2 голосов
/ 23 августа 2011

После обновления сервера до git v1.7.5.4 проблема исчезла.Кажется, что несоответствие между v1.5x (сервер) и 1.7x (локально) было слишком большим.

...