Git: impossible de pousser à partir d'un ordinateur

Question

Un de mes collègues rencontre un problème pour pousser les changements de git sur sa machine. S'il se connecte à une autre machine, il peut pousser très bien - mais de sa machine, quand il essaie de pousser, il obtient l'erreur suivante

 
    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' 

Le serveur est une machine Windows, comme le client. Personne d'autre n'a ce problème - il semble que ce soit un problème d'autorisation du serveur, mais nous l'avons exclu autant que nous le sachions. En outre, le fait qu'il puisse se connecter à une machine différente et pousser, en utilisant le même nom d'utilisateur, donne l'impression qu'il ne s'agit pas d'autorisations de serveur. Des idées sur ce qui pourrait mal se passer ici?

Answer 1

Je ne suis pas un utilisateur de Windows, donc je suis en train de poignarder dans le noir un peu ici. Il semble que le système de fichiers distant est monté et que vous ne faites que pousser (sans utiliser ssh: // ou git: //). Est-ce FS en quelque sorte monté en lecture seule? Peut-il créer/modifier des fichiers là-bas (en dehors de git)?

Answer 2

Peut-être qu'il a créé une branche dans son dépôt local qui existe déjà sur le serveur et que ref ne peut pas être mis à jour car il a été créé par quelqu'un d'autre?

Answer 3

Je sais que c'est la réponse facile de soufflage de sysadmin d'easy-peasy, mais avez-vous vérifié que son harddrive n'est pas plein?

Answer 4

Essayez d'ajouter cette variable de configuration au dépôt distant:

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

Ceux-ci sont généralement fixés par l'option --shared dans git init, lorsque le repo est mis en place. Je ne sais pas comment les autorisations Windows interagissent, donc je ne suis pas sûr que ce soit la solution. Mais je sais que parfois un utilisateur de Linux peut créer des fichiers avec des permissions qui échouent dans une télécommande Git exactement de cette manière. C'est arrivé quand ils appartiennent au groupe approprié mais ne l'ont pas en tant que groupe primaire. Définir le partage des pensions à all contourne cela.

Cela semble se produire avec des mises partagées importées de SVN ou CVS.

Answer 5

Une autre réponse morte de cerveau. Vous êtes sûr d'avoir les autorisations pour lire ces fichiers? Il m'est arrivé à quelques reprises où je vais faire un changement en tant qu'un autre utilisateur par erreur. Puis plus tard, je ne peux pas pousser. Chown est votre ami.

Answer 6

Le problème a fini par être un mot de passe stocké pour ce partage qui permettait l'accès en lecture, mais pas l'accès en écriture. Même lorsque nous avons explicitement monté le lecteur avec le nom d'utilisateur et le mot de passe appropriés, le mot de passe stocké doit avoir été utilisé en arrière-plan, ce qui rendait le suivi difficile. Pour effacer le mot de passe, nous sommes allés à Panneau de configuration, Comptes d'utilisateurs, cliqué sur Avancé, Gérer les mots de passe, et supprimé les informations d'ouverture de session pour le serveur en question. Après cela, tout a fonctionné comme il se doit. J'accepte la réponse de Pat Notz, car elle finit par être un FS en lecture seule. Merci!