#git #http #push
#git #http #толкать
Вопрос:
Я столкнулся с очень странной проблемой с репозиторием git, где я могу редактировать и обновлять существующий файл (css, html, js, xml) и выполнять обычную отправку, НО если я добавляю новые файлы в репозиторий или ЗАМЕНЯЮ существующие файлы, я получаю следующую ошибку, когда я обычно вводил свои учетные данные при успешной отправке:
error: RPC failed; result=22, HTTP code = 502
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Я прочитал множество сообщений по этой проблеме и запустил:
git config http.postBuffer 524288000
из каталога клонирования.
Я запускаю: git версии 1.8.3.2
$ git remote -v outputs the following
origin http://[redacted]/git/TestProgram.git (fetch)
origin http://[redacted]/git/TestProgram.git (push)
В журнале сервера я вижу ошибку Bad Gateway, но я ЗНАЮ, что репозиторий git существует и является правильным, поскольку я могу клонировать его и обновлять файлы — просто не добавлять или заменять файлы в клоне. Я склоняюсь к тому, что это проблема с правами на запись на диск. Кто-нибудь сталкивался с чем-либо подобным — звучит ли эта оценка корректно?
Любые идеи приветствовались бы, поскольку я всю неделю ломал голову над этим.
Ответ №1:
Еще до того, как добраться до конца вашего поста, я подумал «Проблемы с правами доступа к диску». На самом деле я совершенно уверен, что ваше сообщение об ошибке — это именно то сообщение, которое я получил, столкнувшись с той же проблемой, хотя прошло много времени с тех пор, как я использовал git через http.
Комментарии:
1. Спасибо! К сожалению, http — это то, с чем я застрял прямо сейчас. Смогли ли вы обойти проблему, обновив разрешения на диск? Сложная ситуация, поскольку у меня нет прямого доступа к серверу, я пытаюсь подготовить как можно больше информации для встречи с НИМ….
2. Я хотел бы помочь немного больше. В моем случае у меня был прямой доступ к серверу (фактически, я нес ответственность за неправильные разрешения). Проблема не связана конкретно с использованием http, но, конечно, решение немного другое, поскольку с помощью ssh вы должны администрировать разрешения отдельных учетных записей пользователей. Для http вы должны правильно назначить разрешения для любого пользователя, через которого действует http-демон. Вероятно, администратору необходимо добавить пользователя httpd в группу git-users. Я рекомендую предоставить системному администратору четкий тест на успех.