Git: Nie można nacisnąć z jednego komputera.

Question

Jeden z moich współpracowników ma problem z przesuwaniem zmian z git na swoim komputerze. Jeśli on loguje się do innej maszyny, może pchnąć dobrze - ale z jego maszyną, kiedy próbuje wcisnąć dostaje następujący błąd

 
    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' 

Serwer jest maszyną okna, jak jest klient. Nikt inny nie ma tego problemu - wydaje się, że jest to problem z uprawnieniami serwera, ale wykluczyliśmy, o ile możemy to stwierdzić. Ponadto fakt, że może on logować się na innym komputerze i naciskać, używając tej samej nazwy użytkownika, sprawia, że ​​wydaje się, że nie są to uprawnienia serwera. Jakieś pomysły, co tu może pójść źle?

Answer 1

Nie jestem użytkownikiem systemu Windows, więc kłuję w ciemności trochę tutaj. Wygląda na to, że zdalny system plików jest zamontowany i właśnie do niego naciskasz (nie używając ssh: // lub git: //). Czy to FS w jakiś sposób zamontowane tylko do odczytu? Czy może tam tworzyć/modyfikować pliki (poza git)?

Answer 2

Może utworzył oddział w swoim lokalnym repo, który już istnieje na serwerze, a ref nie może zostać zaktualizowany, ponieważ został stworzony przez kogoś innego?

Answer 3

Wiem, że jest to prosta odpowiedź od sysadmin, ale czy zweryfikowaliście, że jego dysk twardy nie jest pełny?

Answer 4

spróbuj dodać do tej zmiennej konfiguracji zdalnego repozytorium:

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

Są one zazwyczaj ustawione przez opcję --shared w git init, gdy repo jest skonfigurowana.

Nie wiem, jak uprawnienia do systemu Windows wchodzą w interakcje, więc nie jestem pewien, czy to jest rozwiązanie. Ale wiem, że czasami użytkownik linuksa może tworzyć pliki z uprawnieniami, które zawodzą w pilocie Git dokładnie w ten sposób. Stało się tak, gdy należą one do właściwej grupy, ale nie mają jej jako grupy podstawowej. Ustawienie dzielenia się repo na all rozwiązuje ten problem.

Wydaje się, że ma to miejsce w przypadku wspólnych replik importowanych z SVN lub CVS.

Answer 5

Kolejna nieumarła odpowiedź. Jesteś pewien, że masz uprawnienia do czytania tych plików? Zdarzyło mi się kilka razy, gdy przez pomyłkę dokonam zmiany jako inny użytkownik. Później nie mogę pchać. Chown jest twoim przyjacielem.

Answer 6

Problem okazał się być zapisanym hasłem dla tego udziału, które umożliwiło dostęp do odczytu, ale nie pozwala na zapis. Nawet jeśli jawnie zamontowaliśmy dysk z odpowiednią nazwą użytkownika i hasłem, zapisane hasło musiało zostać użyte w tle, co utrudniło odnalezienie go. Aby wyczyścić hasło, udaliśmy się do Panelu sterowania, Konta użytkowników, kliknęliśmy Zaawansowane, Zarządzaj hasłami i usunęliśmy dane logowania dla danego serwera. Potem wszystko działało tak, jak powinno. Zgadzam się z odpowiedzią Pat Notza, ponieważ ostatecznie stała się ona tylko do odczytu FS. Dzięki!