خطاف ما بعد الاستجابة بالجيت لا يعمل

Question

نحن نستخدم git مع repo المركزية (باستخدام الوزن). لقد قمت بإنشاء خطاف ما بعد الاستقبال لإنشاء بريد إلكتروني إلى القائمة البريدية DEV كلما تم دفع التغييرات إلى الريبو المركزي ، ولإنشاء وثائق من مجلد الوثائق في GIT Repo.

لذلك ، في ~ git/ لدي دليل ، سوف نسميه "a" يحتوي على استنساخ من ريبو git. يشبه الخطاف اللاحق:

#!/bin/bash
cd ~git/repositories/a.git
. ~git/post-receive-email &> /dev/null
( cd ~git/a && git pull &> ~git/pull_log.log && php ~git/a/scripts/generate_markdown_documentation.php &> ~git/doc_log.log )

يعمل البرنامج النصي للبريد الإلكتروني ، لكن توليد الوثائق ليس كذلك. محتوى pull_log.log هو:

fatal: Not a git repository: '.'

مما يجعلني أعتقد أنه لا يتغير إلى الدليل الصحيح في السطر 5 من البرنامج النصي أعلاه. هل أنا مخطئ؟ كيف يمكنني الحصول على هذا للعمل؟

تعديل: لقد قمت بتحديث الخطاف اللاحق كما هو مقترح في الردود. البرنامج النصي الآن:

#!/bin/bash
function die {
  echo "$*" >&2; exit 1
}

function checkgit {
  [ -d "$1/.git" ] || die "$1 could not possibly be a git repo; $1/.git is not a dir"
}


cd ~git/repositories/a.git
. ~git/post-receive-email &> /dev/null
( set -x
checkgit ~git/a
cd ~git/a
checkgit .
pwd
git pull
php ~git/a/scripts/generate_markdown_documentation.php )

وأحصل على الإخراج التالي من GIT Push:

+ checkgit /var/git/a
+ '[' -d /var/git/a/.git ']'
+ cd /var/git/a
+ checkgit .
+ '[' -d ./.git ']'
+ pwd
/var/git/a
+ git pull
fatal: Not a git repository: '.'
+ php /var/git/a/scripts/generate_markdown_documentation.php

أي مساعدة أخرى؟

أوه ، وإذا قمت بتشغيل البرنامج النصي بنفسي ، فهو يعمل (أقوم بتشغيله بقول السنانير/ما بعد الاستقبال)

اكتشف المشكلة ، بفضل ServerFault - في الأساس ، متغيرات البيئة GIT_DIR و GIT_WORK_TREE يتم تعيينها عندما يتم تشغيل الخطاف ، وتؤثر هذه السحب GIT سلبًا. إلغاء تعيين المتغيرات إصلاح المشكلة.

Answer 1

تحتاج إلى مزيد من التشخيص ، على سبيل المثال ،

function die {
  echo "$*" >&2; exit 1
}

function checkgit {
  [ -d "$1/.git" ] || die "$1 could not possibly be a git repo; $1/.git is not a dir"
}

في هذه المرحلة ، في Subshell مباشرة بعد قوسين ، يمكنك تجربة أشياء مثل

set -x # show exactly what's executed (writes to stderr)
checkgit ~git/a
cd ~git/a && checkgit . && git pull ...

قد تفكر أيضًا في إعادة توجيه Stderr بالكامل من Subshell ، على سبيل المثال ،

( ... ) 2>/tmp/mydiagnosis$$.log

(هذا مقياس مؤقت ولا بأس فقط إذا لم تكن هناك معلومات سرية في السجلات.)

---

طيب Silas ، معلوماتك الإضافية تستبعد الكثير من الاحتمالات المحرجة. أنا أقترب من نهاية بلدي git فو ، ولكن إليك بعض الأشياء الأخرى التي يجب تجربتها:

1. اذهب داخل ~git/a ومعرفة ما إذا كان يمكنك القيام بذلك git pull باليد. هذا يجب أن يفشل.
2. دخلت ~git/a و اهرب git status. هذا يجب أن يفشل أيضا. إذا لم يفعل ذلك ، إذن git يعطيك رسالة خطأ سيئة للغاية.

إذا فشلت كلتا الخطوتين ، ~git/a ليس المستنسخة التي اعتقدت أنها كانت. أعد تسميته ، وقم بعمل استنساخ جديد ، ومعرفة ما إذا كان يمكنك الحصول على المشكلة لتستمر.

إذا نجحت الخطوة الأولى باليد ، فإن شيئًا غريبًا يحدث وأنا محير.

إذا فشلت الخطوة الأولى ولكن الناجح الثاني ، فقد تواجه مشكلة في الفروع:

• ربما الريبو ~git/a تم تعيينه على الفرع الخطأ ، ويحتاج ريبو الخاص بك إلى فرع لا يمتلكه. محاولة git branch -a ومعرفة ما إذا كنت ترى شيئًا غير متوقع.

• ربما يكون لديك الفرع ، لكنه لا يرتبط بشكل صحيح بمستودع بعيد. في هذه المرحلة عليك الغوص ~git/a/.git/config, ، وأنا لا أعرف حقًا كيف أشرح ما يجب أن تتوقعه هناك. في تلك المرحلة ستحتاج إلى ملف حقيقة خبير غيت أنا فقط ألعب واحدة على التلفزيون.

Answer 2

لقد واجهت مؤخرًا مشكلة مماثلة وأعتقد أنها مرتبطة بمتغيرات البيئة التي يحددها GIT ، وتحديداً متغير $ GIT_DIR. إذا كان لديك هذه المجموعة ، تبدأ جميع أوامر GIT على إعادة التجهيز الأخرى في التصرف بغرابة. في الأساس ، أعتقد أنه يجب استدعاء تشغيل GIT سحب داخل الخطاف في بيئة قذيفة محايدة لا تحتوي على تلك المتغيرات الفردية ويؤدي إلى ارتباك GIT ، على الرغم من أنني لم أحسب كيفية القيام بذلك حتى الآن.

Answer 3

unset GIT_DIR هو الحل الذي يعمل للخطأ المميت الذي تراه.

ينطبق هذا على جميع البرامج النصية في السنانير (ما بعد التحديث هو واحد شائع آخر) ، والذي يستخدم أمر GIT بداخله. يستخدم أمر GIT GIT_DIR من ENV بدلاً من PWD.

يرى https://stackoverflow.com/a/4100577 لمزيد من التفسير.