0. Qu’est-ce que hawser ?

Bienvenue ! Si tu as déjà travaillé sur un produit qui vit dans plus d’un dépôt Git, ce cours est fait pour toi. À la fin, tu sauras composer des dépôts, lancer du travail sur toute une flotte, ouvrir des pull requests multi-dépôts, et piloter tout ça depuis un cockpit au clavier — confortablement.

Commençons par le pourquoi. Car une fois que le problème devient clair, chaque commande de haw prend soudain tout son sens.

Plusieurs dépôts, un tout coordonné — voilà le casse-tête que hawser résout.

🧩 Le problème : un produit, plusieurs dépôts

Imagine un vrai produit. Ce n’est presque plus jamais un seul dépôt. C’est une bibliothèque partagée, trois ou quatre services, un SDK, un peu d’infrastructure — chacun dans son propre dépôt Git, avec ses propres branches, sa propre CI, sa propre histoire.

Un produit, éparpillé sur une étagère de dépôts séparés.

Ce découpage, c’est du bon génie logiciel. Mais il a un prix :

• « Quelles versions vont ensemble ? » Le service A fonctionne avec la version 2.1 de la bibliothèque partagée — mais quel commit correspond exactement à la 2.1 ? Et ton collègue a-t-il bien le même ?
• « Une fonctionnalité, cinq pull requests. » Un seul changement touche quatre dépôts. Tu crées une branche dans chacun à la main, tu ouvres quatre PR, et tu pries pour les fusionner dans le bon ordre.
• « Ça marche sur ma machine. » Personne ne peut reproduire l’ensemble exact des commits qui étaient en production en mars dernier, parce que cet ensemble n’a jamais été noté nulle part.

Gérer dix dépôts et leurs versions à la main. Tout va bien. 🔥

Voici l’idée : un seul dépôt avait déjà résolu ces problèmes il y a des années. Ton package.json (ou Cargo.toml) déclare tes dépendances, et un lockfile (package-lock.json, Cargo.lock) fige les versions résolues exactes, pour que tout le monde — toi, ton collègue, le runner de CI — reconstruise un arbre identique.

⚓ Ce que fait hawser

hawser compose un stack logiciel à partir de plusieurs dépôts Git, le fige dans un lockfile, et te laisse piloter chaque build, PR, revue et exécution de CI multi-dépôts depuis un seul endroit.

Ce n’est pas un wrapper autour de Git et ça ne réimplémente pas Git. C’est la couche au-dessus de Git — ce que ton package.json, ton tableau de projet et ton tableau de bord de PR faisaient discrètement pour un seul dépôt, désormais fait pour plusieurs.

L’outil en ligne de commande s’appelle haw. C’est un binaire unique, écrit en Rust, sans aucun runtime à installer.

🧠 Le modèle mental : manifeste → lockfile → stacks

Trois concepts portent tout le système. Apprends-les maintenant et tout le reste en découle.

1. Le manifeste — haw.toml. C’est ton intention. Tu déclares quels dépôts existent, où ils vivent, et quelle révision tu veux. Vois-le comme le bloc dependencies.

2. Le lockfile — haw.lock. C’est la réalité résolue. Quand tu synchronises, haw fige chaque dépôt sur un SHA de commit exact et l’écrit ici. Tu committes ce fichier. Désormais un collègue — ou la CI, ou un auditeur — reconstruit l’arbre identique, octet pour octet.

3. Les stacks. Un stack est une composition nommée de dépôts. Un même manifeste peut définir plusieurs stacks qui partagent les mêmes dépôts sans les copier. (Un stack dans haw, c’est simplement « ces dépôts, ensemble, sous ce nom ».)

haw.toml   (intent)  ─────►  haw sync  ─────►  haw.lock   (pinned SHAs, committed)
   │                                               │
   └── declares repos + stacks                     └── the reproducible baseline

Sur le disque, il n’y a ni sous-modules, ni liens symboliques, ni HEAD détachés — chaque dépôt est un clone Git ordinaire et complet. haw se contente de les garder synchronisés et coordonnés.

🎯 Quand se tourner vers hawser

hawser est agnostique du domaine — un dépôt est un dépôt, un build est la commande shell que tu déclares. Il brille dès qu’un produit est réparti sur plusieurs dépôts :

La boucle — composer → figer → modifier → builder/tester → gouverner — est la même dans chaque cas. Seuls les dépôts et les commandes de build déclarées changent. Voir Domains pour savoir comment chacun s’y rattache.

🚀 Ce que tu sauras faire à la fin de ce cours

• Écrire un haw.toml, le synchroniser, et lire le lockfile en toute confiance.
• Lancer des builds, des tests, des commandes et des recherches sur toute une flotte en parallèle.
• Livrer une fonctionnalité sur N dépôts en un seul changeset — brancher, ouvrir la PR, atterrir dans l’ordre.
• Vivre dans le cockpit TUI et fusionner, approuver et inspecter sans quitter le terminal.
• Étendre haw avec un plugin que tu as écrit toi-même.
• Le brancher dans la CI avec reproductibilité, signature et preuves d’audit.

C’est un ensemble de compétences réel et productif — et nous le construirons une petite étape à la fois.

Et voici où nous allons — le cockpit au clavier dans lequel tu vivras dès le chapitre 4 :

Le cockpit haw : lire la flotte, plonger dans n’importe quel dépôt ou PR, et agir — sans quitter le terminal.

✅ Récapitulatif

• Répartir un produit sur plusieurs dépôts Git est normal, mais cela te coûte en coordination des versions, en PR multi-dépôts et en reproductibilité.
• hawser est un manifeste + lockfile pour une flotte de dépôts — comme package.json + package-lock.json, mais pour des dépôts entiers.
• Trois concepts : manifeste (haw.toml, l’intention) → lockfile (haw.lock, la réalité figée) → stacks (compositions nommées de dépôts).
• La CLI est haw : un seul binaire Rust, aucun runtime.
• Il convient à tout domaine où un produit s’étend sur plusieurs dépôts.

👉 La suite

Installons l’outil sur ta machine et ouvrons le cockpit pour la première fois → 1. Installation et première exécution.