Git: не могу нажать с одного компьютера

Question

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

    D:\Projects\test1\best-practices>git push
    Counting objects: 4, done.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 273 bytes, done.
    Total 3 (delta 1), reused 0 (delta 0)
    error: unable to create temporary sha1 filename ./objects/42: Permission denied

    fatal: failed to write object
    error: unpack failed: unpacker exited with error code
    To //civ3s012/gitrepos/best-practices/.git
     ! [remote rejected] master -> master (n/a (unpacker error))
    error: failed to push some refs to '//civ3s012/gitrepos/best-practices/.git'

Сервер является машиной Windows, как и клиент. Ни у кого больше нет этой проблемы - кажется, это проблема с правами доступа к серверу, но мы исключили это, насколько мы можем судить. Кроме того, тот факт, что он может войти на другой компьютер и нажать, используя то же имя пользователя, создает впечатление, что это не права доступа к серверу. Есть идеи, что здесь может пойти не так?

Answer 1

Я не пользуюсь Windows, поэтому здесь я немного врезаюсь. Похоже, удаленная файловая система смонтирована, и вы просто настаиваете на этом (не используя ssh: // или git: //) Это FS как-то монтируется только для чтения? Может ли он создавать / изменять файлы там (за пределами git)?

Answer 2

Попробуйте добавить эту переменную конфигурации в удаленный репозиторий:

 $ git config core.sharedRepository "all"
 $ git config receive.denyNonFastForwards True

Обычно они устанавливаются параметром --shared в git init, когда устанавливается репо.

Я не знаю, как взаимодействуют разрешения Windows, поэтому я не уверен, что это решение. Но я знаю, что иногда пользователь Linux может создавать файлы с разрешениями, которые терпят неудачу в Git Remote именно таким образом. Это произошло, когда они принадлежат к соответствующей группе, но не имеют ее в качестве своей основной группы. Настройка общего доступа к репо на all обходит это.

Похоже, это происходит с общими репозиториями, импортированными из SVN или CVS.

Answer 3

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

Answer 4

В итоге проблема заключалась в том, что для этой папки был сохранен пароль, который позволял доступ на чтение, но не на запись. Даже когда мы явно смонтировали диск с соответствующим именем пользователя и паролем, сохраненный пароль должен был использоваться в фоновом режиме, что затрудняло его отслеживание. Чтобы очистить пароль, мы зашли в Панель управления, Учетные записи пользователей, нажали «Дополнительно», «Управление паролями» и удалили информацию для входа на данный сервер. После этого все заработало как надо. Я принимаю ответ Пэт Нотц, так как в конечном итоге он был доступен только для чтения. Спасибо!

Answer 5

Еще один умопомрачительный ответ. Вы уверены, что у вас есть права на чтение этих файлов? Случалось со мной несколько раз, когда я по ошибке вносил изменения как другой пользователь. Тогда позже я не могу толкнуть. Чоун твой друг.

Answer 6

Может быть, он создал ветку в своем локальном репо, которая уже существует на сервере, и этот ref не может быть обновлен, потому что он был создан кем-то другим?