Git зависает при нажатии после Total

Недавно я установил VPS с Vultr и настроил удаленный репозиторий git для загрузки моего проекта.

После того, как я добавлю пульт в свой локальный проект и попытаюсь сделать первый толчок к нему, он зависнет после отображения «Всего 119 (дельта 9), повторно использовано 0 (дельта 0)».

Чтобы дать немного контекста:

  • сервер представляет собой новую установку Ubuntu 17.04 x64.
  • У меня есть git версии 2.14.1 локально
  • Я уже делал это раньше на другом VPS с Vultr (Ubuntu 16.04 x64) и все работало нормально
  • Локальный проект git настроен правильно, так как у меня есть удаленный доступ к BitBucket, где я могу успешно отправить проект.
  • Я уже пытался увеличить размер буфера, как это рекомендовано по другим подобным вопросам.
  • Я пытаюсь загрузить новый небольшой проект Laravel - никаких специальных или больших файлов (каждый файл меньше 1 МБ)
  • Я обновил свою версию git до последней доступной версии (с 2.12 до 2.14), как рекомендовано по другим подобным вопросам.
  • мое SSH-соединение работает нормально, и я даже настроил его с уровнем отладки 3, поэтому оно очень подробное (у меня есть журнал ниже)
  • удаленный репозиторий настроен правильно (я попытался создать дополнительный удаленный репозиторий, указав на несуществующее репо на том же сервере, используя то же SSH-соединение, и я получаю правильное сообщение об ошибке от GIT, которое он не может найти репо)
  • Я настроил репо с --shared и без него, но результат тот же
  • Я даже ждал (более 8 часов) и ничего не произошло, никаких сообщений об ошибках, все еще висело
  • Я пробовал любое другое решение, которое смог найти за 2 дня по этой теме, и все равно получаю тот же результат (даже несколько раз воссоздавал свое репо, пробовал разные имена, пробовал chmod 777 как для моего репо, так и для моего рабочего каталога на сервере и т. д. .)

Вот часть подробного вывода ssh на git push (после проверки ключей ssh):

debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to 45.63.116.43 ([45.63.116.43]:22).
debug2: fd 4 setting O_NONBLOCK
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x08
debug2: client_session2_setup: id 0
debug1: Sending command: git-receive-pack '/var/repo/hc-teaser.git'
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
Counting objects: 119, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (104/104), done.
Writing objects: 100% (119/119), 277.89 KiB | 5.91 MiB/s, done.
Total 119 (delta 9), reused 0 (delta 0)
debug2: channel 0: read<=0 rfd 4 len 0
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug3: send packet: type 96
debug2: channel 0: input drain -> closed
debug2: channel 0: rcvd adjust 65689

После этой последней строки он просто висит на неопределенный срок.


person Antonio    schedule 20.10.2017    source источник
comment
Взгляните на этот вопрос: stackoverflow.com /вопросы/15843937/   -  person jmarks    schedule 05.12.2019


Ответы (1)


Проблема заключалась в неверных правах доступа к целевой папке. Когда я создал целевую папку, я использовал «sudo», поэтому владельцем был установлен root. Когда я изменил владельца целевой папки на своего пользователя (тот, который использовался для отправки репозитория) и группу на www-data, все заработало как шарм.

Итак, я узнал, что когда git не может переместить файлы из вашего репозитория в целевую папку, потому что у него нет надлежащей авторизации, он не показывает никаких отчетов об ошибках, он просто ждет бесконечно.

person Antonio    schedule 06.12.2019