Комментарии 17
Вы устройство руками создавали? Ошибка.
Правильно:
mount|grep '/dev'
udev on /dev type devtmpfs (rw,relatime,size=1994644k,nr_inodes=206376,mode=755)
А /dev/null вам не «удалили», а «не создали» в процессе запуска контейнера/докера/mountnamespace'а/etc.
Правильно:
mount|grep '/dev'
udev on /dev type devtmpfs (rw,relatime,size=1994644k,nr_inodes=206376,mode=755)
А /dev/null вам не «удалили», а «не создали» в процессе запуска контейнера/докера/mountnamespace'а/etc.
Интересно, а при чём здесь git? :)
Не при чем. При чем тут авторы git, которые поленились организовать более подробный вывод ошибок.
Вот одна из частых ошибок:
fatal: The remote end hung up unexpectedly
Сообщение от капитана Очевидность. А можно было бы хотя бы указывать в процессе какой операции удаленный конец оборвал соединение
Вот одна из частых ошибок:
fatal: The remote end hung up unexpectedly
Сообщение от капитана Очевидность. А можно было бы хотя бы указывать в процессе какой операции удаленный конец оборвал соединение
Полагаю, что 'No space left on device' уже системное сообщение, git его просто перебросил.
Да не суть — выскочить могла любая программа. При чём молча.
Да не суть — выскочить могла любая программа. При чём молча.
вот именно!
Вот к этому — «просто перебросил» — и есть основная претензия.
unix way — три-четыре утилиты перебросили системное сообщение — в итоге теряется контекст и оказывается, что вам показывают ошибку, которая слабо коррелирует с исходной командой.
И приходится писать вот такие мелкие постики, просто для того, чтобы сохранить информацию вида «а вы выключатель в шкафу поищите»
Чтобы в следующий раз проблему решило быстрое гугление, а не вдумчивое чтение исходников git
Вот к этому — «просто перебросил» — и есть основная претензия.
unix way — три-четыре утилиты перебросили системное сообщение — в итоге теряется контекст и оказывается, что вам показывают ошибку, которая слабо коррелирует с исходной командой.
И приходится писать вот такие мелкие постики, просто для того, чтобы сохранить информацию вида «а вы выключатель в шкафу поищите»
Чтобы в следующий раз проблему решило быстрое гугление, а не вдумчивое чтение исходников git
unix way — три-четыре утилиты перебросили системное сообщение — в итоге теряется контекст и оказывается, что вам показывают ошибку, которая слабо коррелирует с исходной командой.
Так он же перед этим явно сказал, что ошибка возникла при записи в stdout. Ошибка такая-то, и выдал системную, что уже заставляет задуматься (что вы и сделали).
Ну как вот вы, на месте разработчиков гита, разрулили бы такую нестандартную ситуацию? Стали оборачивать обработчиками исключения каждое конкретное обращение к stdout, или всё-таки каким-нибудь базовым классом обошлись?
я не силен во внутренних алгоритмах гита, и читать исходники у меня времени нету.
но просто предположение:
git вызвал что-то типа patch file /dev/null
patch попытался записать в свой stdout, который на самом деле направлен в ФАЙЛ /dev/null
на разделе, занятом на 100%
а ошибка-то про запись в stdout. не надо обрабатывать исключения, достаточно вывести команду, которая вернула ошибку. Было бы намного информативнее.
но просто предположение:
git вызвал что-то типа patch file /dev/null
patch попытался записать в свой stdout, который на самом деле направлен в ФАЙЛ /dev/null
на разделе, занятом на 100%
а ошибка-то про запись в stdout. не надо обрабатывать исключения, достаточно вывести команду, которая вернула ошибку. Было бы намного информативнее.
Да я тоже не силён в них, просто предполагал. Понимаете, практически любой мало-мальски сложный код можно улучшить. Всегда. И заниматься этим можно до бесконечности. Думаю, у разработчиков гита есть более важные проблемы, которые надо решать, а не предусматривать все мыслимые и немыслимые варианты работы в хаотичном окружении.
А что
git fetch ... >/dev/null, например, должен был бы вывести? Откуда git fetch ... может узнать куда перенаправили stdout?
«Клонирование того же репозитория на этот же сервер в другой каталог проходило без проблем.»
Эта цитата противоречит причине возникновения ошибки.
Умопомрачительной полезности пост.
Можно было придумать более «кричащий» заголовок.
Как забить под завязку /dev/null
Что если /dev/null «отправить в /dev/null»
Git! А теперь когда вы обратили внимание, /dev/null бывает не создано.
Как забить под завязку /dev/null
Что если /dev/null «отправить в /dev/null»
Git! А теперь когда вы обратили внимание, /dev/null бывает не создано.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Работа с сообщениями об ошибках — git