Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierTech Généraliste

Freenet-git - Le dépôt Git sans serveur

Par : Korben ✨
12 août 2026 à 12:41

Depuis ce printemps, sachez qu'un git clone ordinaire peut maintenant récupérer un dépôt qui n'existe sur aucun serveur spécifique. En fait, le code est stocké dans Freenet, le réseau pair-à-pair qu'Ian Clarke a relancé en mars. Et comme y'a plus d'hébergeur, bah y'a plus personne pour fermer un compte ou shooter le dépôt.

Car Git est décentralisé depuis toujours et fonctionne très bien comme ça, puisque chaque clone contient l'historique complet, ce qui permet à 2 clones de se synchroniser directement. Ce qui lui manquait par contre, c'était l'hébergement, et c'est là-dessus que les forges que nous connaissons, Github en tête, sont venues capitaliser. Y'a bien des initiatives comme Grasp qui essaie d'en sortir grâce au protocole Nostr mais freenet-git lui range carrément le dépôt dans un contrat que les nœuds recopient, et se publie lui-même à l'adresse freenet::99TmCayXn6Tm/freenet-git.

Cloner ou publier du code exige donc le paquet freenet-git et un nœud qui tourne sur votre machine, ce qui fait qu'on ne supprime pas vraiment le serveur, mais on le ramène juste chez soi.

Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Le socle compte plus que l'application dans cette présentation. Les contrats et les delegates forment la couche où une app tourne sans backend, et quatre tournent déjà dessus : River pour le chat de groupe, Delta pour les sites, Atlas pour la recherche, et freenet-git pour le code. Mail, Raven et Harvest existent aussi, à un stade plus jeune.

L'adresse du dépôt sort des 12 premiers caractères de la clé publique de son propriétaire, et à ce stade expérimental, lui seul peut pousser dedans. Y'a pas non plus de pull requests, ni d'issues puisque c'est le modèle du noyau Linux d'avant les forges, où chacun publie son clone et le mainteneur vient y piocher ce qui l'intéresse.

Reste le plus dur maintenant, retrouver un dépôt.

Car sans annuaire, un nœud doit deviner lequel de ses voisins mettra le moins de temps à trouver ce qu'on lui demande. Le réseau traite ça comme un problème d'apprentissage et parie sur le bon voisin à partir des requêtes passées grâce à Renegade, une bibliothèque open source sortie en 2021, capable de faire ce calcul.

Installer freenet-git

Il faut une chaîne Rust, et ~/.cargo/bin doit être dans votre PATH. Les installeurs du nœud sont sur freenet.org/quickstart.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Rust n'entre dans le PATH qu'au shell suivant, donc ouvrez un nouveau terminal avant la commande d'après. Elle dépose deux binaires, freenet-git et le remote helper que Git appellera tout seul.

cargo install freenet-git

Cloner un dépôt qui existe déjà

Aucune identité n'est nécessaire pour lire. La bibliothèque standard de Freenet fait un bon test, elle porte son historique complet et ses tags.

git clone freenet::96rknpy1GYhZ/freenet-stdlib

Publier le vôtre

C'est create qui publie réellement le contrat. Il affiche PUT confirmed by host et l'adresse du dépôt, dont le préfixe se recopie dans le remote. La phrase de passe voyage par une variable d'environnement parce que Git garde la main sur l'entrée standard durant le push.

freenet-git init-identity --name "Votre Nom" --email [email protected]
cd ~/code/mon-projet
freenet-git create --name mon-projet
# -> URL: freenet:VOTRE_PREFIXE/mon-projet
git remote add freenet freenet::VOTRE_PREFIXE/mon-projet
export FREENET_GIT_PASSPHRASE='votre-phrase-de-passe'
git push freenet main

Et voilà ! Avec ça vous pouvez faire du vrai git décentralisé même si la vraie limite est ailleurs...

En effet, les nœuds gardent en cache ce qu'on leur réclame et évacuent le reste, donc un dépôt que personne ne clone finit au bout d'un moment par ne plus être clonable. Et ça c'est dommage... C'est pourquoi une commande (rescue), le remet en circulation depuis une machine qui a encore les données. Le projet ne présente toutefois pas ça comme un bug, mais comme son modèle de durabilité actuel.

Mais autant le savoir avant d'y déposer votre code.

Source

GitWand - Il trie vos conflits Git et vous montre pourquoi

Par : Korben ✨
27 juillet 2026 à 18:52

perso, je n'ai jamais été très à l'aise avec Git. Je l'utilise tous les jours, mais c'est vraiment pas ma came. Dès que ça devient trop compliqué, genre conflit de merge qui repeint des dizaines de fichiers en rouge, je ne m'en sors plus ^^.

Heureusement qu'il y a l'IA pour m'aider dans des moments difficiles ! Mais si vous n'aimez pas confier la gestion de vos merges à un LLM en aveugle, je vous invite à découvrir GitWand, développé par Laurent Guitton, qui s'occupe uniquement de la gestion des conflits avec Git et vous laisse gérer le reste.

Gitwand, c'est donc un client Git open source, sous licence MIT, qui classe chaque bloc conflictuel selon des règles fixes et ne résout automatiquement que ceux dont le résultat ne fait aucun doute.

Pour cela, il dispose de plusieurs patterns déterministes :

  • same_change, c'est quand les deux branches ont écrit exactement la même chose.
  • whitespace_only ne voit qu'une indentation qui a bougé,
  • reorder_only les mêmes lignes remises dans un autre ordre.
  • Un numéro de version qui change, lui, tombe dans value_only_change.
  • Et puis il y a complex, le fourre-tout des modifications qui se chevauchent pour de vrai. Celle-là n'est jamais tranchée toute seule.
  • git rerere rejoue les résolutions que vous avez déjà tranchées à la main,
  • et Mergiraf se branche directement dans git merge pour arbitrer en lisant l'arbre syntaxique de votre code.

Ce qui change ici, c'est que chaque décision est justifiée. En effet, chaque bloc reçoit un score de confiance ainsi qu'une trace qui nomme le motif retenu ligne par ligne.

Par exemple, si une branche écrit const theme = 'dark', et l'autre const theme = localStorage.getItem('theme') ?? 'dark', hé bien l'outil garde la seconde, étiquette sa décision prefer-theirs, et affiche 97 % de confiance à côté.

Sur la page d'accueil, l'outil annonce 95 % des conflits triviaux résolus automatiquement. Le moteur est aussi exposé aux agents IA via un serveur MCP, ce protocole qui branche des outils externes sur des assistants comme Claude Code ou Cursor. L'installation se fait comme ceci : claude mcp add gitwand -- npx -y @gitwand/mcp.

L'agent réclame un aperçu, récupère les blocs déjà réglés, et ne garde que les cas ambigus, avec les trois versions du code sous les yeux. Le modèle ne touche qu'à ce qu'aucune règle ne sait faire, soit l'inverse de ce qu'on voit d'habitude.

Le projet est jeune et ça se voit. Mais ça vaut le coup d'essayer parce que je pense que ça peut rendre de nombreux services. L'app existe pour macOS, Linux et Windows, l'interface est traduite en français, et elle se double d'une ligne de commande (npm i -g @gitwand/cli) et d'une extension VS Code.

Si l'interface graphique vous tente, je vous avais montré Gittyup dans le même registre, et pour les irréductibles du terminal j'avais présenté Lazygit .

À vous maintenant de commencer par gitwand resolve --dry-run --verbose pour voir "à blanc" ce qu'il trouve et comment il aurait tranché pour le merge.

Merci à Laurent pour le lien !

Source

Reviewer des patches git par mail sans quitter Thunderbird

Par : Korben ✨
20 juillet 2026 à 15:02

Marc Coquand avait très envie d'embarquer son équipe dans un nouveau genre de workflow Git à base d'emails et c'est pour ça qu'il a créé thunderbird-patch-review .

Il s'agit d'une extension pour Thunderbird qui, lorsque vous ouvrez un mail qui contient une série de patchs, vous propose un bouton "Review" vous permettant d'accéder à une interface de relecture Git qui va vous être très familière, vous allez voir.

Ensuite, si la série des patchs vous convient, vous pouvez tous les approuver directement sur votre dépôt local avec la commande git-am sans jamais avoir à quitter votre client mail.

Pour lancer Git, l'extension utilise une API expérimentale maison qui embarque tout le nécessaire dans son paquet sans host de messagerie native à installer séparément. Ça fait un truc en moins à configurer et l'addon vérifie que tout est OK dans un worktree jetable, avant de valider la review.

Comme ça, s'il y a un conflit, le bouton Apply se grise et les erreurs remontent dans l'interface pour que vous puissiez toutes les revoir une par une et faire un retour propre à l'auteur.

Cet add-on a été vibe-codé avec GLM 5.2 et construit pour répondre aux besoins de son équipe. Il hésitait sincèrement à le partager parce que le monde n'est pas encore prêt pour le Vibe Coding, mais il explique sur son site qu'il y avait un sérieux manque d'outils dans l'écosystème pour pouvoir travailler sur des revues de patch directement dans son client mail.

Donc tant pis, yolo, il l'a publié quand même et je pense que ça devrait vous intéresser. Comme quoi faire bosser un agent pour soi n'oblige pas à le planquer.

Maintenant, les patches qui arrivent en pièce jointe ne sont pas encore gérés, les mails en HTML seul non plus, et la collecte d'une série ne cherche que dans le dossier du message ouvert. De plus, l'add-on n'est pas encore publié sur le store Thunderbird, donc vous devrez le packager vous-même en .xpi depuis la racine du projet :

git clone git://mccd.space/thunderbird-patch-review
cd extension && zip -qrX ../patch-review.xpi .

Ensuite, vous chargez le fichier obtenu via le menu engrenage du gestionnaire de modules complémentaires (Installer un module depuis un fichier) et c'est réglé ! Rien de méchant si vous avez déjà bidouillé des extensions Thunderbird, genre Send Later pour planifier vos envois dont je vous parlais il y a un petit moment maintenant.

Voilà, si vous faites déjà du git par email, ça vaut le détour. Le code est en EUPL 1.2, et tout se passe ensuite sur la mailing list de Marc.

Source

❌
❌