Git невозможно нажать после добавления

Хорошо, у меня проблемы, что я не могу исправить с той недели. Я использую git (на github) для хранения моих проектов. Недавно я добавил в него несколько новых файлов без проблем, но когда я использую "git push", у меня есть ошибка тайм-аута.

Я использую Ubuntu 12.04, с ssh (по умолчанию) и https.

Итак, я решил сделать новую копию депо (git clone). После этого я изменяю существующий файл, фиксирую его и нажимаю... с успехом!

Итак, я добавляю остальные (в новой копии), фиксирую их и нажимаю. И проблема снова возникает: невозможно Вот консольный вывод:

time git push
Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 16.61 KiB, done.
Total 11 (delta 2), reused 0 (delta 0)
^C

real    7m59.383s
user    0m0.008s
sys 0m0.004s

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

Я удаляю git и переустанавливаю его без изменений.

Если у вас есть идея решить эту проблему.

изменить 1

git remote -v

origin  [email protected]:Krozark/projet_compilation.git (fetch)
origin  [email protected]:Krozark/projet_compilation.git (push)

изменить: Решение

sudo ifconfig [wlan0] mtu 1460 (lower than 1500)

Ответы

Ответ 1

Я видел эту ту же проблему, с которой столкнулся коллега, и это была сеть, связанная с SSH. В то время мы использовали VPN-соединение, и в итоге она была слишком высокой (MTU) сетью (это было 1492, если я помню правильно), мы потрудились с меньшими значениями, пока не начали работать. Так что что-то делать с разбиением пакетов в сети казалось.

Не уверен, что это относится к вам, хотя вам не мешает попробовать изменить MTU сети на меньшее значение, чтобы увидеть, работает ли оно.

Конечно, если это проблема на стороне Github, это не будет фактором (факт, что вы можете создать новое репо и отталкивать, заставляет меня полагать, что это не связано с MTU).

Ответ 2

Как вы предположили, что привязка вашего MTU была эффективной для решения проблемы, я бы рекомендовал более целенаправленное решение.

iptables -t mangle -I OUTPUT 1 -o wlan0 -d 207.97.227.239 \
    -p tcp --dport 22 --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1420

Это захватывает начальное согласование TCP с сервером (только для SSH на github.com IP) и заставляет MSS равняться 1420. Это фактически то же самое, что и установка MTU, но более избирательно. Это хорошо в некоторых ситуациях, когда вы не можете легко сэкономить изменения MTU и должны будут повторно применять его каждый раз, когда интерфейс был взят/вверх.

MSS должен быть на 40 меньше MTU, чтобы разрешить 40-байтовый заголовок TCP + сегмент данных (MSS - максимальный размер сегмента).

Самая распространенная причина, по которой нужно сделать что-то вроде этого (т.е. получить MTU ниже 1500), - это VPN и туннели. PMTU предназначен для решения этого вопроса, но он не срабатывает в слишком многих ситуациях, в результате чего вам необходимо вручную настроить MTU для определенных путей. Использование правила iptables позволяет вам адаптировать свой трафик по-разному для разных путей проблемы, а не заставлять вас устанавливать MTU на самый низкий общий знаменатель для всех путей. Проблема с этим заключается в том, что вы постепенно уменьшаете свою эффективную пропускную способность, увеличивая коэффициент заголовка до данных.

Ответ 3

Если локально нормально (т.е. ваши git и ssh работают нормально), то это должно быть проблемой на удаленной стороне:

Отметьте Состояние GitHub.

Сегодня

3:22 UTC Мы изучаем проблемы с одним из наших файловых серверов, небольшое количество репозиториев недоступно.

Возможно, на вас могут повлиять текущие проблемы с периодическим доступом, упомянутые в GitHub.


Или это проблема подключения (например, отсутствующий маршрут VPN)