Question fréquentes sur Git pour le Projet GL

De Ensiwiki
Révision de 10 janvier 2013 à 21:00 par Nguyphuo (discussion | contributions) (Ajout paragraphe sur conflit de version gcov)

Aller à : navigation, rechercher

Une liste des quelques erreurs les plus fréquentes avec Git pour le Projet GL. Merci de conserver cette liste courte, pour les détails, il existe déjà une FAQ Git et le manuel utilisateur.

Problèmes après utilisation du mail ou de scp

Vous avez échangé des modifications entre membres d'une equipe, en dehors de Git (par email, scp, cle usb, ...), et vous avez beaucoup de conflits incomprehensible :

\Rightarrow c'est normal. Git ne sait rien sur ce qu'il se passe par email ou scp, il croit que plusieurs developpeurs ont fait des modifications similaires (et en general pas tout a fait identiques). En bref, si vous utilisez autre chose que Git pour vous echanger du code, attendez-vous a des problemes.

Problème avec gedit

Si EDITOR=gedit, "git commit" se plaint d'un message de commit vide.

\Rightarrow Le problème se produit lorsqu'un gedit est déjà lance (un nouvel appel à gedit demande au programme existant d'ouvrir le fichier, et termine immédiatement, donc Git croit que gedit a fini le travail). 2 solutions : ne pas utiliser EDITOR=gedit, ou bien fermer toutes les fenêtres gedit avant de faire un commit.

Problème avec gvim

Si EDITOR=gvim, "git commit" se plaint d'un message de commit vide.

\Rightarrow Même problème qu'avec gedit (ci-dessus), mais il y a une solution plus satisfaisante : utiliser « gvim -f » à la place de « gvim ».

git push échoue avec le message non-fast-forward

"git push" echoue avec le message :

To ssh://glXX@ensibm.imag.fr/~/git/
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'ssh://glXX@ensibm.imag.fr/~/git/'

\Rightarrow il faut faire un pull avant le push, une nouvelle révision est disponible dans l'archive partagée.

fatal: Unable to create '.../index.lock': File exists

La plupart des opérations échouent avec le message :

fatal: Unable to create '/home/ensi2a/bob/Projet_GL/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.

\Rightarrow à moins que vous ne veniez de trouver un bug dans Git, ce message se produit quand :

  • Une autre instance de Git est en train de s'exécuter dans le même répertoire (typiquement, un "git commit" qui a lancé un éditeur de texte et qui attend que cet éditeur de texte termine). Solution : faire en sorte que cette autre instance termine proprement (typiquement : en fermant l'éditeur de texte lancé par "git commit")
  • Vous avez tué brutalement un processus git (typiquement, Control-C dans un terminal). Solution : supprimer le fichier index.lock, et pour la prochaine fois, penser à ne plus tuer brutalement les processus ...

Plus rien ne marche, et les autres entrées de cette page ne s'appliquent pas

Pas de panique, l'intérêt de Git est justement que vos données sont à l'abri. La solution la plus simple (et sans doute la plus brutale) est de refaire un clone depuis l'archive partagée :

cd
mv Projet_GL Projet_GL.casse
git clone ssh://glXX@ensibm.imag.fr/~/git/ Projet_GL

(on garde une copie de la copie de travail qui pose problème, on ne sait jamais)

Si vous aviez des commits dans votre copie de travail qui n'avaient pas encore été « pushées » vers l'archive partagée, ils sont récupérables avec

cd ~/Projet_GL
git pull ~/Projet_GL.casse

Quand la situation est rétablie, on peut faire un « git push » pour envoyer nos modifications vers l'archive partagée, et continuer à travailler comme avant.

gcov affiche un message de problème de version et fait un out of memory

Si vous travaillez sur votre machine personnelle, il se peut que vous rencontriez un message du type :

$ gcov Syntaxe/Src/lexical.adb
Syntaxe/Src/lexical.gcno:version '406*', prefer '407*'

gcov: out of memory allocating 14156016440 bytes after a total of 135168 bytes

La raison vient d'une utilisation de gnatmake différente de celle de gcov. Dans l'exemple, gnatmake utilise gcc-4.6 pour faire les compilations et la commande gcov réfère à la version 4.7. Mais en principe, si gcc-4.6 est installé pour les besoins de gnatmake, il y a de fortes chances pour que gcov-4.6 soit aussi installé. Il suffit alors d'utiliser la commande gcov-4.6 au lieu de gcov.