Git: не могу нажать с одного компьютера
У одного из моих коллег возникли проблемы с переносом изменений из git на его машину. Если он заходит на другую машину, он может просто нажать, но со своей машины, когда он пытается нажать, он получает следующую ошибку
D:\Projects\test1\best-practice>git push Подсчет объектов: 4, сделано. Сжатие объектов: 100% (2/2), сделано. Написание объектов: 100% (3/3), 273 байта, сделано. Итого 3 (дельта 1), повторно использованная 0 (дельта 0) ошибка: невозможно создать временное имя файла sha1./objects/42: разрешение отклонено, неустранимо: не удалось записать объект ошибка: не удалось распаковать: распаковщик завершился с кодом ошибки To //civ3s012/gitrepos/ лучшие практики /.git! [удалено отклонено] master -> master (н / п (ошибка распаковщика)): ошибка: не удалось отправить некоторые ссылки в '//civ3s012/gitrepos/best-practices/.git'
Сервер является машиной Windows, как и клиент. Ни у кого больше нет этой проблемы - кажется, это проблема с правами доступа к серверу, но мы исключили это, насколько мы можем судить. Кроме того, тот факт, что он может войти на другой компьютер и нажать, используя то же имя пользователя, создает впечатление, что это не права доступа к серверу. Есть идеи, что здесь может пойти не так?
6 ответов
Я не пользуюсь Windows, поэтому здесь я немного врезаюсь. Похоже, удаленная файловая система смонтирована, и вы просто настаиваете на этом (не используя ssh:// или git://). Это FS как-то монтируется только для чтения? Может ли он создавать / изменять файлы там (вне git)?
Попробуйте добавить эту переменную конфигурации в удаленный репозиторий:
$ git config core.sharedRepository "all"
$ git config receive.denyNonFastForwards True
Они обычно устанавливаются --shared вариант в git init, когда репо настроено.
Я не знаю, как взаимодействуют разрешения Windows, поэтому я не уверен, что это решение. Но я знаю, что иногда пользователь Linux может создавать файлы с разрешениями, которые терпят неудачу в Git Remote именно таким образом. Это произошло, когда они принадлежат к соответствующей группе, но не имеют ее в качестве основной группы. Настройка общего доступа к репо all обходит это.
Похоже, это происходит с общими репозиториями, импортированными из SVN или CVS.
Я знаю, что это простой ответ сисадмина, но вы убедились, что его жесткий диск не полон?
В итоге проблема заключалась в том, что для этой папки был сохранен пароль, который позволял доступ на чтение, но не на запись. Даже когда мы явно смонтировали диск с соответствующим именем пользователя и паролем, сохраненный пароль должен был использоваться в фоновом режиме, что затрудняло его отслеживание. Чтобы очистить пароль, мы зашли в Панель управления, Учетные записи пользователей, нажали "Дополнительно", "Управление паролями" и удалили информацию для входа на данный сервер. После этого все заработало как надо. Я принимаю ответ Пэт Нотц, так как в конечном итоге он был доступен только для чтения. Спасибо!
Еще один мертвый ответ. Вы уверены, что у вас есть права на чтение этих файлов? Случалось со мной несколько раз, когда я по ошибке вносил изменения как другой пользователь. Тогда позже я не могу толкнуть. Чоун твой друг.
Может быть, он создал ветку в своем локальном репо, которая уже существует на сервере, и этот ref не может быть обновлен, потому что он был создан кем-то другим?