lingo pull

Récupère les sorties du push le plus récent et les écrit sur le disque, avec détection des conflits par rapport au fichier de verrouillage.

lingo pull [--force] [--dry-run]

Quand l’utiliser#

lingo push se termine dès que l’exécution est envoyée. pull permet donc d’en récupérer les résultats. Exécutez-la après n’importe quel push sans --wait — et lorsqu’un push avec --wait n’a pas pu écrire :

• Terminal fermé en pleine traduction. Rouvrez-le, lancez lingo pull — il reprend là où l’exécution s’est arrêtée.
• Plus tard dans le même job CI. Une étape exécute lingo push, puis une étape ultérieure, sur le même runner et dans le même checkout, exécute lingo pull pour récupérer les résultats. Les autres machines y ont accès une fois qu’ils sont commités.
• Reprise du travail une fois l’exécution terminée, mais avant que push ait pu écrire. Coupure réseau, processus interrompu — pull termine le travail.

Comment il retrouve l’exécution#

pull lit ~/.lingo/runs/<hash>.json, où <hash> est dérivé du chemin racine absolu du projet. Ce fichier enregistre le dernier runId de push. Sans lui, pull renvoie une erreur :

Error: No saved run state for this project (looked for ~/.lingo/runs/<hash>.json) — run
       `lingo push` first so we know which run's outputs to pull.

Ce fichier est propre à chaque machine et se trouve en dehors du dépôt (voir Configuration pour comprendre pourquoi).

Détection des conflits#

Avant d’écrire chaque cible, pull compare :

• Le hash du fichier local sur le disque
• Le hash enregistré dans .lingo/lock.json comme dernière version connue côté serveur

S’ils correspondent → aucune modification locale, l’écrasement est sûr. S’ils diffèrent → des modifications locales existent ; un pull les écraserait. pull s’interrompt :

Error: 3 conflict(s) — rerun with --force

Le fichier de verrouillage fait foi ici — il suit ce que le serveur a écrit en dernier, pas le contenu source. Les modifications manuelles des fichiers traduits que vous souhaitez conserver doivent être commitéees (pour qu’elles survivent à pull) ou récupérées avec --force (pour qu’elles soient écrasées).

Options#

--force / -f#

Écrase les fichiers cibles locaux qui ont divergé du fichier de verrouillage. À utiliser après avoir passé en revue les conflits et décidé que la version du serveur fait autorité (par exemple, si quelqu’un d’autre a poussé une mise à jour du glossaire qui doit primer).

Workflow recommandé :

git status                          # stash or commit local edits first
git stash                           # if you want to keep them aside
lingo pull --force
git stash pop                       # re-apply your edits, resolve conflicts manually

--dry-run#

Affiche ce que pull ferait sans toucher au système de fichiers :

lingo pull --dry-run

Affiche le nombre de fichiers qui seraient écrits et combien sont déjà synchronisés. Utile en CI pour vérifier que rien n’a dérivé.

Sortie#

Succès :

✓ Pulled run lrg_a8c...: wrote 12 file(s), 4 already in sync.

Simulation :

Dry run complete. 16 file(s) already in sync.

L’exécution a échoué ou a été annulée :

Run lrg_a8c... is failed, not pulling yet.

(pull attend qu’une exécution encore en attente ou en cours se termine, avec le même affichage de progression que push --wait, puis écrit les résultats. Une exécution en échec ou annulée n’a rien à récupérer — voir Runs, state, and recovery.)

Cas limites#

• Aucun push précédent. Même erreur que ci-dessus. Il n’existe pas de notion de « récupérer des traductions qui existent quelque part sur le serveur » — pull cible toujours une exécution précise.
• État d’exécution pointant vers une exécution supprimée ou expirée. Le moteur renvoie 404 ; pull le signale clairement. Supprimez ~/.lingo/runs/<hash>.json et relancez push.
• Moteur différent dans .lingo/config.json de celui sur lequel l’exécution a été créée. Incompatibilité d’ID du moteur — la CLI renvoie une erreur avec les ID. Relancez push avec le moteur actuel.