Gerrit/Dépannage
Ceci est le point central qui documente les problèmes rencontrés avec Git, Gerrit et git-review.
ssh
Bad server host key: Invalid key length
Si cette erreur apparaît lors des tests ssh tels que :
tony@thor:~$ ssh -p 29418 shelluser@gerrit.wikimedia.org
Bad server host key: Invalid key length
Essayez de réduire la longueur minimale de la clé RSA, par exemple :
$ ssh -p 29418 -o RequiredRSASize=1024 shelluser@gerrit.wikimedia.org
The authenticity of host '[gerrit.wikimedia.org]:29418 ([208.80.154.151]:29418)' can't be established.
RSA key fingerprint is SHA256:j7HQoQ6fIuEgDHjONjI2CZ+2Iwxqgo2Ur5LbPqBgxOU.
No matching host key fingerprint found in DNS.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[gerrit.wikimedia.org]:29418' (RSA) to the list of known hosts.
**** Welcome to Gerrit Code Review ****
Hi AccountName, you have successfully connected over SSH.
Unfortunately, interactive shells are disabled.
To clone a hosted Git repository, use:
git clone ssh://shelluser@gerrit.wikimedia.org:29418/REPOSITORY_NAME.git
Connection to gerrit.wikimedia.org closed.
$
You can save this configuration permanently by editing your ~/.ssh/config:
# Work around error: Bad server host key: Invalid key length
Host gerrit.wikimedia.org
RequiredRSASize 1024
git clone
fatal: The remote end hung up unexpectedly
Voir https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-unexpectedly-while-git-cloning pour avoir quelques idées, et déboguer le problème en initialisant la variable d'environnement GIT_TRACE=1.
The authenticity of host '[gerrit.wikimedia.org]:29418 (....)' can't be established.
The authenticity of host '[gerrit.wikimedia.org]:29418 ([2620:0:861:2:208:80:154:137]:29418)' can't be established.
RSA key fingerprint is SHA256:j7HQoQ6fIuEgDHjONjI2CZ+2Iwxqgo2Ur5LbPqBgxOU.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
Dans ce cas, veuillez vérifier si la valeur indiquée à la ligne RSA key fingerprint is SHA256:j7HQoQ6fIuEgDHjONjI2CZ+2Iwxqgo2Ur5LbPqBgxOU correspond à l'empreinte digitale publiée sur wikitech:Help:SSH_Fingerprints/gerrit.wikimedia.org:29418.
Si les valeurs sont identiques, presser simplement « yes ».
Si pour une raison quelconque les valeurs sont différentes, il peut y avoir un problème de sécurité et vous devez immédiatement arrêter d'essayer de vous connecter.
Echec scp de l'accroche commit-msg avec "subsystem request failed on channel 1"
Les commandes copier / coller de Gerrit Clone with commit-msg hook contiennent une commande scp qui télécharge le fichier du message de commit vers le dépôt local.
Les versions OpenSSH >=9 échoueront car scp tentera d'utiliser sftp[1] puisque scp est obsolète.
Pour télécharger le fichier, ajouter un -O à la commande. Par exemple,
scp -O -p -P 29418 username@gerrit.wikimedia.org:hooks/commit-msg "projectname/.git/hooks/"
git pull
Please, commit your changes or stash them before you can merge.
Pour annuler vos modifications (et tout ce que vous avez dans la zone de réserve) :
git stash
git stash clear
Maintenant vous pouvez réaliser l'extraction.
git-review
git-review indique certains problèmes rencontrés avec l'installation de l'accroche commit-msg
Si vous rencontrez cette erreur quand vous essayez de pousser des modifications avec git-review, vous ne travaillez pas avec un dépôt qui a été cloné via ssh. Vous devez cloner les dépôts en utilisant ssh, et non pas http ni https, pour pousser avec succès les modifications avec git-review.
git-review indique "missing Change-id in commit message"
Si vous recevez un message missing Change-Id après avoir effectué git review alors votre /.git/hooks/commit-msg est probablement incorrect. Ce qui devrait ressembler à :
CHANGE_ID_AFTER="Bug|Issue"
MSG="$1"
# Recherchez un Change-Id unique et ajoutez-le s'il est absent
#
add_ChangeId() {
clean_message=`sed -e '
/^diff --git a\/.*/{
s///
q
}
/^Signed-off-by:/d
/^#/d
' "$MSG" | git stripspace`
if test -z "$clean_message"
then
return
fi
Vous obtiendrez également un message indiquant que le Change-ID est manquant lorsque vous essayez de fusionner (git cherry-pick) une modification de git qui n'a pas Change-ID.
Il apparaît que l'accroche n'est pas appelée par cherry-pick mais qu'elle est heureusement appelée par git commit -c commit-id.
Dans l'exemple ci-dessous, nous allons déplacer la modification triviale de bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc à partir du master de git dans le projet de mediawiki/core vers REL1_19.
Pour corriger cela, utiliser l'option -n (sans faire le commit) sur git cherry-pick :
git cherry-pick -n bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc
git commit -c bd7a268e4be2da23ba0b9943c3b0ba1ac88294dc
Malheureusement, si vous voulez ajouter l'ID du commit original au message (comme le fait git cherry-pick -x) vous devez l'ajouter vous-même.
Si vous oubliez d'exécuter git review -s, remote se plaindra à propos de missing Change-id in commit message.
Mais il suggèrera aussi un message de commit avec la ligne de Change-Id: INNNXXXNNN....
Soit :
- Copiez cette ligne commençant par Change-Id, exécutez
git commit --amend, et collez la ligne Change-Id sous votre message commit dans l'éditeur de texte qui s'ouvre. - Ou il suggèrera une correction de l'accroche :
gitdir=$(git rev-parse --git-dir); scp -p -P 29418 freephile@gerrit.wikimedia.org:hooks/commit-msg ${gitdir}/hooks/
Vous devriez pouvoir utiliser l'une ou l'autre des méthodes (mais l'accroche ne fonctionne pas pour moi), puis répétez git review -R, et cela devrait se terminer.
git-review indique "You have more than one commit that you are about to submit"
Si git review affiche un avertissement pour plusieurs commit, suivi d'une liste de commit d'autres personnes qui ont déjà été fusionnés, effectuez le contournement suivant :
- Répondre "no" pour arrêter git-review.
- Exécuter
git fetch --allougit remote update(Les deux commandes font exactement la même chose, elles récupèrent des objets dans tous les dépôts distants; alors choisissez simplement la commande dont vous vous souvenez facilement et oubliez l'autre). - Réexécuter
git-review
Ceci permet de s'assurer que git-review dispose d'une vue à jour du master distant.
Contexte
Ceci a été corrigé en 2012 mais le bogue est réapparu.
Les projets Wikimedia en souffrent de manière disproportionnée parce que defaultrebase=0 est initialisé sur la plupart des projets Wikimedia, et le bogue ne se déclenche si le rebase est désactivé (en utilisant soit ce paramètre, soit le drapeau -R).
git-review indique "Cannot query patchset information"
git-review ne fonctionne pas correctement si git génère des sorties qui ne sont pas en anglais. Vous verrez une erreur similaire à :
$ git review -d 62474
Cannot query patchset information
The following command failed with exit code 255
"ssh -x -p None gerrit query --format=JSON --current-patch-set change:62474"
-----------------------
Bad port ' None'
-----------------------
Cela est dû à un un bogue dans git-review.
Pour contourner cela sur un système Linux, appliquez le correctif du rapport de bogue ci-dessus, ou installez un alias qui oblige git à générer ses sorties en anglais.
Pour faire cela, mettez ceci dans votre fichier de configuration bashrc ou équivalent :
alias git="LANG=C git"
git-review indique "ConfigParser.NoSectionError: No section: 'updates'"
Si cela se produit (phab:T57732, corrigé dans les versions plus récentes de git-review) :
$ git review -s
Traceback (most recent call last):
File "/usr/local/bin/git-review", line 1196, in <module>
main()
File "/usr/local/bin/git-review", line 1108, in main
needs_update = latest_is_newer()
File "/usr/local/bin/git-review", line 179, in latest_is_newer
if not configParser.getboolean("updates", "check"):
File "/usr/lib/python2.7/ConfigParser.py", line 368, in getboolean
v = self.get(section, option)
File "/usr/lib/python2.7/ConfigParser.py", line 607, in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'updates'
L'ajout de quelque chose comme ceci dans .gitreview résoud le problème :
[updates]
check=off
git-review n'accepte pas le commit des fusions
Si vous avez fusionné une branche de développement, et que vous souhaitez maintenant soumettre un commit pour fusionner dans Gerrit, git review ne vous permettra peut-être pas de le faire.
Il peut vous demander de soumettre de nombreuses modifications pour l'une des branches fusionnées, ou bien perturber le commit.
Pour éviter cela, poussez le commit directement dans Gerrit en évitant git review :
git push gerrit HEAD:refs/for/master
Pour plus d'informations, voir la documentation Gerrit.
git-review indique "Working tree is dirty"
Si vous recevez un message Working tree is dirty après avoir fait git review essayez de faire git add pour le ou les fichiers modifiés (ou créés), puis git commit, puis git review.
(Ceci a été observé sous Mac OS X avec un ancien client git).
git-review indique "Authentication failed"
Si vous voyez
remote: Unauthorized
fatal: Authentication failed for 'https://gerrit.wikimedia.org/r/some/code/repository'
puis vous essayez de pousser via HTTPS au lieu de SSH que vous aviez défini plus tôt. Vous aimeriez configurer git pour utiliser le SSH distant à la place du HTTPS distant.
Gerrit
Gerrit indique "Your change could not be merged due to a path conflict"
Vous devez rebaser votre modification afin de pouvoir la fusionner.
Pour les impatients :
git checkout master git pull git-review -d <change #> git rebase origin/master git status <edit "both modified" files in status report> git add <files> git rebase --continue git review
Explication complète
Vous avez donc soumis une modification qui a été approuvée. Mais le temps qu'elle soit relue, d'autres validations sont intervenues qui ont modifié le dépôt principal et qui provoquent maintenant un conflit. Gerrit n'arrive pas à fusionner automatiquement vos modifications dans le dépôt, vous devrez les corriger et les soumettre à nouveau.
L'exemple ci-dessous est basé sur un cas d'utilisation réel : la correction 2514 sur le dépôt operations/puppet
D'abord, récupérez le changement en utilisant git-review et son option -d :
(production)$ git-review -d 2514
Downloading refs/changes/14/2514/1 from gerrit into review/hashar/ignore_pyc
Switched to branch 'review/hashar/ignore_pyc'
(review/hashar/ignore_pyc)$
hashar est le nom d'utilisateur, ignore_pyc est le nom du sujet qu'il a fourni.
Notez la manière dont git-review vous place automatiquement sur la branche.
Il vous faut maintenant faire un rebase en haut de la branche main.
La modification sur gerrit montre la branche, il suffit d'ajouter gerrit/ devant.
Pour cette modification dans le dépôt operations/puppet, la branche principale est production, donc rebasez sur gerrit/production; pour les autres dépôts, c'est généralement origin/master.
(review/hashar/ignore_pyc)$ git rebase gerrit/production
First, rewinding head to replay your work on top of it...
Applying: pyc files are now ignored
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging .gitignore
CONFLICT (content): Merge conflict in .gitignore
Failed to merge in the changes.
Patch failed at 0001 pyc files are now ignored
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".
(no branch)$
La clé dans la sortie ci-dessus est la ligne commençant par CONFLICT.
Il donne le nom du fichier que git n'a pas pu rebaser correctement, généralement parce que votre correctif le modifie et que les changements dans la branche principale l'ont également modifié.
L'exécution de git status confirme cela :
(no branch)$ git status
# Not currently on any branch.
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: .gitignore
#
(no branch)$
Corriger le fichier qui pose problème (dans ce cas .gitignore).
Il y aura des marques <<<<, ====, >>> autour des lignes qui posent problème, vous devez les corriger.
Pendant le conflit de fusion, git crée des fichiers file.BASE.xxx, file.LOCAL.xxx, et file.REMOTE.xxx avec les trois versions source.
Vous pouvez utiliser un outil de fusionnement à trois panneaux pour choisir les lignes à utiliser;
git mergetool wraps the use of a merge tool.
Une fois que vous avez terminé l'édition, vous devez ajouter cette modification pour qu'elle soit utilisée pendant le rebase puis continuer à corriger les patches qui posent problème :
(no branch)$ git add .gitignore
(no branch)$ git rebase --continue
Applying: pyc files are now ignored
(review/hashar/ignore_pyc)$
Comme il n'y avait plus de correctifs à corriger, on vous a replacé sur la branche review/hashar/ignore_pyc. En regardant le journal :
$ git log -n5 --decorate --pretty=oneline
* a3631d2 (HEAD, review/hashar/ignore_pyc) pyc files are now ignored (2 seconds ago
* 1b6cd67 (gerrit/production, production) ensure sample config file removed (18 hours ago)
...
Vérifiez que votre modification est cohérente avant de la soumettre à nouveau dans gerrit.
Utilisez simplement git show <sha1 du commit>, comme git show a3631d2.
Vous pouvez éventuellement la valider par un amend pour signaler que vous avez rebasé la modification.
Maintenant soumettez à nouveau vos modifications dans le dépôt :
(review/hashar/ignore_pyc)$ git review
remote: Resolving deltas: 0% (0/2)
To gerrit.wikimedia.org
(review/hashar/ignore_pyc)$
Revenant à Gerrit, la différence est qu'il existe un nouvel ensemble de corrections en attente de relecture.
Bravo pour la correction concernant votre premier conflit de rebase ou de fusion.
Dans Gerrit vos modifications ne sont pas fusionnées après avoir reçu un +2
Si quelqu'un entre un +2 Code Reviewed, cela devrait déclencher une série de constructions et de tests automatisés.
Le flux de travail est décrit dans l'Intégration continue.
Dans Gerrit, le robot utilisateur jenkins ajoutera un commentaire
- Starting gate-and-submit jobs. https://integration.wikimedia.org/zuul/
Suivez le lien pour voir la progression des tests pour votre modification que Zuul a soumise à Jenkins.
Si vous ne voyez pas le commentaire Starting gate-and-submit jobs dans gerrit, regardez sur https://integration.wikimedia.org/zuul/ Il montre tout ce que Zuul a soumis à Jenkins, et la valeur longueur de la file d'attente en haut donne le nombre d'événements qui n'ont pas encore été traités. Si votre tâche n'apparaît pas en dessous sur la page ci-dessous et que la longueur de la file d'attente est différente de zéro, c'est qu'elle est encore en file d'attente; Zull et Jenkins sont probablement occupés et il vous faut attendre. Mais si la longueur de la file d'attente est de 0 et que vos modifications n'apparaîssent pas, cela signifie que cela ne va pas se produire et vous devez les soumettre à nouveau. Notez que les nouveaux dépôts doivent être ajoutés manuellement à la liste des robots jenkins.
Si les tests requis sont tous passés sans problème (notez que certains tests sont non votants), alors jenkins-bot ajoutera un commentaire Build succeeded suivi de Change has been successfully merged into the git repository.
Dans Gerrit, Jenkins attribue un -2 vous obligeant à supplanter Jenkins
Tout d'abord, vous ne devriez jamais avoir à le faire.
(Jusqu'à présent, la raison était de reporter un changement sur une ancienne version pour laquelle les tests avaient échoué).
Si Jenkins a reçu un -2 il ne vous est généralement pas possible de réaliser la fusion.
Ce que vous devez faire :
- Supprimer la relecture de code du robot jenkins Verified (cliquer sur
[x]) - Relire le dernier ensemble de corrections avec Verified +2 en plus de Code-Review +2 (c'est normalement réservé à Jenkins, mais puisque nous l'évitons, nous remplaçons son score par le nôtre)
- Cliquer sur Publier et soumettre
Erreur Permission denied (publickey)
En général, vous devriez vérifier la sortie verbeuse de SSH avec ssh -v -p 29418 <username>@gerrit.wikimedia.org (vous pouvez obtenir plus de détails avec -vv / -vvv mais le débogage de niveau 1 est généralement suffisant).
Il y a beaucoup de raisons pour que vous puissiez voir cette erreur apparaître, la plupart étant liées à un problème de configuration locale, comme la clé SSH qui n'est pas lisible ou qui ne correspond pas à celle que vous avez téléversée dans Gerrit, ou encore qui utilise un algorithme obsolète (voir aussi T276486).
fatal: Could not read from remote repository.
Si vous obtenez l'erreur
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
First of all, if you are on Windows, make sure to use Git Bash as a command line tool.
OpenSSH a désactivé le support pour les anciennes clés id_rsa depuis la version 8.8.
ssh-keygen continuera néanmoins à générer des clés RSA s'il est utilisé sans argument.
De telles clés seront simplement ignorées et donnera le message d'erreur cryptographique ci-dessus.
Vous devez soit créer une nouvelle clé id_ed25519 comme décrit dans le Tutoriel Gerrit (recommandé), soit permettre à nouveau la prise en charge des clés RSA avec l'option HostkeyAlgorithms de OpenSSH, tel que décrit dans les notes de diffusion.
Ensuite, veuillez partager les sorties de la commande git remote show origin, exécuter la commande git concernée avec les traces utilisant les variables de débogage activées telles que GIT_CURL_VERBOSE=1 GIT_TRACE=1, et tester si ssh -p 29418 username@gerrit.wikimedia.org affiche Hi username, you have successfully connected over SSH. (remplacer username dans cette commande par le nom utilisateur de votre compte développeur)
fatal: The remote end hung up unexpectedly
Si vous obtenez l'erreur
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Ensuite vous n'êtes pas encore tout à fait connecté avec votre clé ssh.
Solution: exécutez ssh-add ~/.ssh/id_rsa pour qu'il vous demande la question secrète pour votre clé et ajoutez-la à chaîne de la clé active.
Alors vous pouvez vérifier ce que contient la chaîne de votre clé avec ssh-add -l.
Puis essayer de pousser pour une nouvelle relecture.
L'empreinte digitale du serveur Gerrit est
dc:e9:68:7b:99:1b:27:d0:f9:fd:ce:6a:2e:bf:92:e1
alors vous pouvez dire yes quand on vous demande d'ajouter cette empreinte digitale au fichier known_hosts.
Gardez à l'esprit que gerrit écoute sur le port 29418 et si pour une raison quelconque vous avez oublié de spécifier le numéro du port, vous pouvez cliquer sur le daemon SSH "normal" qui écoute sur le port 22 (ce dernier a une empreinte digitale de clé RSA b5:e9:dc:b2:dd:6e:70:f7:18:8a:dc:a3:5d:ab:99:4d).
Pour vérifier si la connectivité SSH et l'authentification de la clé publique sont disponibles, utilisez ssh -p 29418 username@gerrit.wikimedia.org qui doit afficher Hi username, you have successfully connected over SSH.
Votre modification n'a pas démarré les tests
Les tests ne sont exécutés que par les utilisateurs de la liste d'autorisation de la CI. Voir la Liste des autorisés à l'intégration continue pour plus d'informations.
Divers
push via HTTPS (quand SSH n'est pas opérationnel)
| Contenu étendu |
|---|
|
Cette méthode est utile pour soumettre vos modifications dans Gerrit lorsque SSH n'est pas opérationnel (par exemple quand il est bloqué par votre institution ou par un fournisseur internet). Si SSH n'est pas opérationnel, vous devriez voir un des messages d'erreur suivants : ssh: connect to host gerrit.wikimedia.org port 29418: Connection refused ssh: connect to host gerrit.wikimedia.org port 29418: Network is unreachable Vous pouvez aussi essayer explicitement la commande : ssh -p 29418 your-user-name@gerrit.wikimedia.org
Si SSH est fonctionnel, cette commande doit créer la sortie suivante : Connection to gerrit.wikimedia.org closed by remote host. Connection to gerrit.wikimedia.org closed. Lorsque SSH n'est pas opérationnel, vous avez besoin d'un mot de passe HTTP(S) qui peut être généré dans la Configuration du compte de Gerrit sous mot de passe http. Après avoir généré le mot de passe, validez avec commit toutes les modifications de vos correctifs et utilisez git push https://<username>@gerrit.wikimedia.org/r/mediawiki/core HEAD:refs/for/master Les informations d'authentification doivent être entrées pour soumettre avec succès les modifications. L'URL donnée ci-dessus est pour le noyau MediaWiki et variera en fonction des extensions. Par exemple si vous souhaitez pousser sur Extension:LiquidThreads, la commande serait : git push https://<username>@gerrit.wikimedia.org/r/mediawiki/extensions/LiquidThreads HEAD:refs/for/master Pour utiliser toujours https, cloner initialement avec : git clone https://<username>@gerrit.wikimedia.org/r/mediawiki/core Ou sélectionner un référentiel existant avec : git remote set-url origin https://<username>@gerrit.wikimedia.org/r/mediawiki/core Vous pouvez alors utiliser Vous pouvez utiliser git-credential-store pour enregistrer votre mot de passe HTTPS afin de ne pas le re-saisir à chaque fois.
Accroche du commit et Change-IDUn problème majeur qui apparait si on utilise HTTPS pour soumettre les modifications est que l'attache du commit n'est pas automatiquement attachée. Une solution pour cette approche est de faire échouer un push. De cette manière, le message d'erreur va mettre en évidence le Change-Id; voir l'exemple ci-dessous : Username for 'https://gerrit.wikimedia.org': xxxxxx Password for 'https://xxxxxx@gerrit.wikimedia.org': Counting objects: 25, done. Delta compression using up to 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 448 bytes | 0 bytes/s, done. Total 4 (delta 3), reused 0 (delta 0) remote: Resolving deltas: 100% (3/3) remote: Processing changes: refs: 1, done remote: ERROR: missing Change-Id in commit message footer remote: Suggestion for commit message: remote: Commit message appears here remote: remote: Change-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx remote: remote: Hint: To automatically insert Change-Id, install the hook: remote: gitdir=$(git rev-parse --git-dir); scp -p -P 29418 xxxxxx@gerrit.wikimedia.org:hooks/commit-msg ${gitdir}/hooks/ remote: remote: To https://gerrit.wikimedia.org/r/mediawiki/extensions/Test ! [remote rejected] HEAD -> refs/for/master (missing Change-Id in commit message footer) error: failed to push some refs to Copiez maintenant le change ID et amendez votre commit. Ajoutez toujours le Change-ID sur la dernière ligne de votre message de commit. git commit --amend Cela ouvrira un éditeur pour modifier le message de commit. Collez le Change-ID sur la dernière ligne du message et sauvegardez-le. Voir l'exemple : Your commit summary Your commit message Bug: Txxxxx Change-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Maintenant, vous pouvez pousser avec succès dans Gerrit.
Ajouter l'accroche de commit automatiquementPour obtenir le script du message de commit : scp -p -P 29418 USERNAME@gerrit.wikimedia.org:hooks/commit-msg <local path to your git>/.git/hooks/
Voir https://gerrit.wikimedia.org/r/Documentation/cmd-hook-commit-msg.html pour les détails.
Etre derrière un serveur proxyCette section n'a pas été testée; veuillez mettre à jour cette section avec des informations à jour si des problèmes paraissent.
Si vous êtes derrière un serveur proxy, vous devez aussi cloner via HTTPS.
Assurez-vous que la variable d'environnement GIT_CURL_VERBOSE=1 git clone https://gerrit.wikimedia.org/r/pywikibot/core.git
En cas de problème, essayez de fournir directement HTTPS_PROXY=proxy_server GIT_CURL_VERBOSE=1 git clone https://gerrit.wikimedia.org/r/mediawiki/core.git
ou d'utiliser les options de git directement : GIT_CURL_VERBOSE=1 git -c http.proxy="proxy_server" clone https://gerrit.wikimedia.org/r/mediawiki/core.git
Cette dernière option devrait également fonctionner pour les serveurs proxy SOCKS, en utilisant GIT_CURL_VERBOSE=1 git -c http.proxy="socks5://socks_server" clone https://gerrit.wikimedia.org/r/mediawiki/core.git
|
push via SSH uniquement (quand HTTPS est désactivé ou non opérationnel)
Ajouter la section suivante à votre .gitconfig local :
# Utiliser SSH sur HTTPS
[url "ssh://username@gerrit.wikimedia.org:29418/"]
pushInsteadOf = https://gerrit.wikimedia.org/r/
git commit --amend indique you are in the middle of a merge -- cannot amend
Lorsqu'après avoir rebasé et fusionné votre
git commit --amend
ce qui donne
message: fatal: You are in the middle of a merge -- cannot amend.
appliquez ces étapes et réappliquez vos modifications
git stash
git reset --hard
git checkout master
git review -d <change number>
git stash pop
git commit -a --amend
Si après que le robot jenkins git review a envoyé le courriel
Ce changement n'a pas pu être fusionné automatiquement avec l'état actuel du dépôt. Veuillez rebaser votre modification et téléverser un nouvel ensemble de corrections.
Cela pourrait signifier que la branche master du serveur a maintenant des conflits pour fusionner vos corrections.
Voir l'Utilisation avancée de Gerrit pour savoir comment les corriger.
Your change requires a recursive merge to resolve
Si vous obtenez l'erreur Your change requires a recursive merge to resolve, vous devez rebaser les modifications sur le master.
- Vérifiez que votre branche master est à jour :
git pull origin master - Créer et passer sur une nouvelle branche sur laquelle vous allez extraire l'ensemble de corrections avec le conflit :
git checkout -b BRANCHNAME - Extraire les modifications conflictuelles sur cette branche. Vous pouvez copier / coller la commande correcte trouvée dans la section Télécharger de Gerrit review. Cela devrait ressembler à :
git fetch ssh://awjrichards@gerrit.wikimedia.org:29418/mediawiki/extensions/MobileFrontend refs/changes/14/3414/3 && git checkout FETCH_HEAD - Rebaser encore le master :
git rebase master - Pousser les modifications dans Gerrit pour relecture :
git review - Relire à nouveau l'ensemble des corrections dans Gerrit, puis soumettre les modifications à fusionner sur le master.
master"_and_"failed to push some refs"">
[remote rejected] master -> master et failed to push some refs
Si le push est fait sur une branche différente de refs/for/master, vous recevrez des lignes similaires à :
$ git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 709 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 0% (0/1)
To ssh://username@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples
! [remote rejected] master -> master (prohibited by Gerrit)
error: failed to push some refs to 'ssh://username@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples'
Cela signifie que vous avez essayé de valider sur la branche master au lieu de soumettre vos modifications à la relecture.
Voici une erreur similaire où git review essayait de pousser sur une branche distante non existante :
! [remote rejected] T12345 -> T12345 (prohibited by Gerrit)
error: failed to push some refs to 'ssh://username@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples'
Avec git branch vous pouvez voir la branche sur laquelle vous vous trouvez actuellement. Essayer de rebaser pour pousser correctement :
git pull --rebase origin master
git review -R
[remote rejected] HEAD -> refs/publish/master/??? (Cannot merge change to another branch)
Lorsque vous essayez de choisir une modification ou la fusion d'une branche entière en mode cherry-pick et ensuite que vous la soumettez à la relecture, Gerrit sera très perturbé si vous ne donnez pas explicitement le nom de la branche que vous modifiez. Vous pourriez voir des erreurs telles que :
! [remote rejected] HEAD -> refs/publish/master/mwalker_test (change 59546 closed)
ou
! [remote rejected] HEAD -> refs/publish/master/mwalker_test (no new changes)
Dans ce cas, vous devez vous assurer que le fichier .gitreview de votre branche a la bonne option de branche par défaut (par exemple, il doit indiquer la branche que vous essayez de modifier) ou vous devez pousser manuellement le refspec en utilisant git push gerrit HEAD:refs/for/<branch>
! [remote rejected] HEAD -> refs/publish/master (prohibited by Gerrit: not permitted: create)
Si vous utilisez git-review pour soumettre vos patches dans gerrit, assurez-vous d'avoir la version 1.27 ou plus récente (et pas la 1.26). git-review 1.26 ne fonctionne pas avec Gerrit 3.
! [remote rejected] HEAD -> refs/changes/79/550379/2 (cannot add patch set to 550379.)
Cela se produit quand vous n'êtes pas l'auteur original (le propriétaire) du changement (dans ce cas le 550379). Pour pouvoir ajouter un nouvel ensemble de corrections à une validation dont vous n'êtes pas l'auteur, veuillez demander l'ajout au groupe Trusted-Contributors des contributeurs confirmés sur Gerrit. Chaque membre de ce groupe peut vous ajouter à la demande.
Committer email address does not match your user account.
remote: ERROR: committer email address (email) remote: ERROR: does not match your user account.
Deux problèmes possibles peuvent être à l'origine de cette erreur. Si l'adresse courriel que git affiche est l'adresse courriel que vous avez l'intention d'utiliser avec Gerrit, vous devez ajouter cette adresse courriel dans Gerrit, et vous assurer d'avoir cliqué sur le lien de confirmation dans le courriel que Gerrit vous a envoyé. Puis essayer de pousser à nouveau.
Cependant, si git renvoie un courriel absurde (comme celui que vous n'utilisez plus, ou une adresse mail locale comme root@localhost), faites ceci :
$ git config --global user.email yournewemail@example.org
$ git commit --amend --reset-author
Pour le faire localement juste pour ce dépôt, faites plutôt :
$ git config user.email yournewemail@example.org
$ git commit --amend --reset-author
Puis essayer de pousser à nouveau.
Echec de la construction à cause d'un conflit de fusion
Après que le robot jenkins git review ait envoyé le courriel Ce changement n'a pas pu être fusionné automatiquement avec l'état actuel du dépôt. Veuillez rebaser votre modification et téléverser un nouvel ensemble de corrections. Cela pourrait signifier que la branche master du serveur a maintenant des conflits de fusion avec votre correctif.
- Assure-vous que votre branche master est alignée parfaitement avec le master de git (pour éviter que git review ne se plaigne de multiples commit)
$ git checkout master
$ git fetch --all
$ git reset --hard origin/master
- Extraire pour relecture, rebaser, et faire commit à nouveau
$ git review -d <patchNumber>
$ git rebase master
# Corrigez les conflits de fusion et ajoutez les avec ''git add''
$ git rebase --continue
$ git review -R
Si l'erreur se produit même après avoir rebasé vos corrections comme ci-dessus, essayez de modifier arbitrairement votre message de commit, puis exécutez à nouveau git review (relatif à bogue 53895).
message Everything up-to-date après le git push
Si vous essayez de faire git push après avoir fait git commit vous pourriez recevoir une réponse Everything up-to-date. Vous n'avez pas poussé la branche. Vous devez exécuter git review pour enregistrer vos modifications dans gerrit, et seule la branche de gerrit sera mise à jour. Cela semble être un effet de bord de l'extraction de la branche master en février 2012.
Dans certains projets (comme par exemple test/), il est possible de faire git push au lieu de git review et de réussir le push. Il est probablement préférable de ne pas faire cela, car cela perturbe ceux qui découvriront plus tard vos changements et ne sauront pas d'où ils proviennent.
Impossibilité de marquer une extension
Si vous voulez marquer votre extension, vous devez vous connecter à gerrit en utilisant ssh et non https. Dans votre .git/config, l'URL distante devrait ressembler à :
[remote "origin"]
url = ssh://username@gerrit.wikimedia.org:29418/r/mediawiki/extensions/yourextension
fetch = +refs/heads/*:refs/remotes/origin/*
Pour marquer une extension, utiliser git tag suivi de git push :
git tag -a v1.4 -m 'my version 1.4'
git push --tags
Plugin install error: TypeError: self.onAction is not a function
Si vous voyez cette erreur, réinitialisez le cache de votre navigateur.
Pour certains, Ctrl+F5 ou ⇧ Shift+Ctrl+F5 (ou toute autre combinaison acceptée par votre navigateur) ne suffit pas.
Si vous rencontrez encore l'erreur après avoir pressé la combinaison de touches F5, essayez de purger vos caches complètement.
Par exemple avec Firefox, suivez les étapes 1-6 de
Si vous utilisez un navigateur différent, il devrait vous permettre aussi d'effacer le contenu du cache quelque part dans les paramètres. Veuillez rechercher l'information dans les pages d'aide de votre navigateur et suivre les instructions.
Bad server host key: Invalid key length
Les utilisateurs qui utilisent Fedora 33 ou plus récent avec les paramètres de cryptage DEFAULT ou FUTURE ne peuvent pas utiliser Git avec SSH pour Gerrit.
(relatif à T326204)
Les utilisateurs affectés peuvent travailler sur ce problème en diminuant la longueur minimale demandée pour la clé pour gerrit.wikimedia.org particulièrement dans le fichier ~/.ssh/config :
Host gerrit.wikimedia.org
RSAMinSize 1023
Notes
- ↑ Secure File Transfer Protocol (sftp)