Sortie de jj v0.43.0

• Le système de gestion de versions compatible Git jj v0.43.0 ajoute jj run, qui permet d’exécuter des commandes sur plusieurs changesets afin d’automatiser davantage les tâches répétées de vérification et de correction
• jj run utilise un working copy dédié pour chaque changeset, et propage aussi les modifications et conflits issus de commandes qui modifient le working copy, comme cargo check ou cargo fix
• Cette version inclut aussi des changements affectant les configurations existantes et l’usage des revsets, comme git_head(), git_refs(), la résolution de symboles au style Git et la suppression de ui.revsets-use-glob-by-default
• S’ajoutent également jj show --reversed, la recherche de configuration dans /etc/jj, jj config gc, jj gerrit upload -o, la fonction de revset forks() et le style de texte barré
• Des correctifs ont été apportés à la gestion de l’identité des fichiers sous Windows, aux snapshots de working copy immuable, aux avertissements sur les URL distantes en doublon, ainsi qu’à un problème de corruption d’objets Git loose sur Intel Raptor Lake et aarch64

---

Aperçu de la version

• jj est un système de gestion de versions compatible Git, simple mais puissant
• La v0.43.0 ajoute jj run, une nouvelle commande pour appliquer une commande à plusieurs changesets
• Les instructions d’installation pour démarrer sont disponibles dans les installation instructions

Exécuter des commandes par changeset : jj run

• jj run permet d’exécuter la même commande sur plusieurs changesets
• Chaque changeset utilise un working copy dédié et isolé
• La commande exécutée peut mettre à jour le working copy, et les modifications ainsi produites ainsi que les conflits sont propagés de manière appropriée
• Exemples d’utilisation
  • jj run -- cargo check --all-features
  • jj run -- cargo fix

Suppressions ayant un impact sur la compatibilité

• Les fonctions git_head() et git_refs(), déjà obsolètes dans les revsets et templates, ont été supprimées
• Les symboles au style Git comme refs/heads/main ne sont plus interprétés comme des révisions
  • Il faut désormais utiliser la syntaxe <name> ou <name>@<remote> pour les bookmarks/tags
• L’option obsolète ui.revsets-use-glob-by-default a elle aussi disparu
• jj bookmark track et untrack ne prennent plus en charge le motif <kind>:<bookmark>@<remote>
  • La syntaxe symbolique <bookmark>@<remote> reste prise en charge
  • Issue liée : #9226

Nouvelles fonctionnalités

• jj show prend désormais en charge le flag --reversed
• jj recherche aussi les fichiers de configuration dans /etc/jj
• jj config gc nettoie les configurations de dépôts supprimés ou déplacés du dossier ~/.config/jj/repos
  • Issue liée : #9362
• jj gerrit upload prend en charge les flags -o / --option, qui fonctionnent comme git push -o ou --push-option
• jj git fetch rebase les révisions enfants d’une révision réécrite en se basant sur le change ID
  • Auparavant, quand plusieurs révisions d’une stack avaient un bookmark attaché, la révision réécrite et ses révisions enfants n’étaient pas toujours toutes rebasées
  • Les révisions enfants immuables ne sont pas rebasées
• La fonction de revset forks() a été ajoutée
  • Elle renvoie tous les commits ayant au moins 2 enfants
• Le paramètre colors prend désormais en charge le style de texte barré via { crossed-out = true }

Problèmes corrigés

• Sous Windows, la récupération de l’identité d’un fichier à partir de son chemin ne suit plus les liens symboliques
  • Le comportement est désormais aligné sur Unix
  • Auparavant, deux liens symboliques pointant vers la même cible étaient considérés comme le même fichier
  • Cette vérification d’identité est utilisée lors de l’écriture du working copy pour détecter les alias des répertoires réservés .git et .jj
  • Issue liée : #8924
• Lorsque le working copy était dans un état immuable, jj crée désormais une nouvelle révision de working copy pendant le snapshot
  • Auparavant, une nouvelle révision était créée juste après que le working copy devenait immuable
  • Issues liées : #7751, #9338
• jj git remote add affiche désormais un avertissement si l’URL de fetch ou l’URL de push effective du nouveau remote est exactement identique à celle d’un remote existant
  • Issue liée : #413
• Un problème de corruption d’objets Git loose a été corrigé sur les CPU Intel Raptor Lake et sur aarch64
  • Auparavant, jj pouvait signaler qu’un commit avait réussi, puis git fsck échouait ensuite avec incorrect data check, corrupt loose object ou missing blob
  • Les opérations jj suivantes pouvaient alors aussi échouer avec corrupt deflate stream

[GN⁺]

Avis sur Lobste.rs

• jj run m’enthousiasme beaucoup

• Je suis content que la dépréciation ait été annulée pour jj bookmark track/untrack <name>@<remote>
  Devoir taper --remote à chaque fois a toujours été pénible

• La partie indiquant que des objets Git loose corrompus ont été corrigés sur Intel Raptor Lake CPU et aarch64 ressemble à un bug intéressant
  J’aimerais bien lire un billet de blog à ce sujet s’il en sort un 😃

• Jusqu’ici, je pensais que tous les objets Git corrompus que j’avais vus étaient dus à des rollbacks du système de fichiers
  Après un arrêt brutal, les rollbacks f2fs produisaient parfois des états de disque assez intéressants, et c’est très intéressant d’apprendre qu’il y avait tout simplement quelque chose de cassé de ce côté-là

• Je me demande en quoi jj run diffère de jj fix
  Même dans l’exemple du changelog, ils lançaient cargo fix avec jj run, donc les deux semblent clairement se recouper

  • jj run crée une copie de travail complète et exécute la commande dedans
    jj fix envoie le contenu d’un seul fichier à une commande via un pipe, puis utilise la sortie comme nouveau contenu de ce fichier
    Si l’outil s’adapte bien à jj fix, typiquement comme un formateur ou un linter, c’est beaucoup plus rapide, mais jj run est plus flexible
  • Si je comprends bien, run exécute une commande pour chaque changement, tandis que fix applique un filtre à chaque fichier modifié
    Dans mon cas, cela reviendrait à lancer la suite de tests avec run pour vérifier que chaque commit est valide, puis à exécuter un formateur sur les fichiers avec fix
    Je n’ai pas encore fait la mise à jour, ce n’est que mon interprétation

• Je vais probablement bidouiller un peu avec jj run, mais vu ma façon d’utiliser direnv, je pense que cela risque fort de devenir plus compliqué que nécessaire