Sortie de jj v0.42.0 - système de gestion de versions compatible Git

 (github.com/jj-vcs)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Passage à l’allocateur mémoire mimalloc pour améliorer les performances multithread
  • Suppression des options de commande obsolètes comme jj commit --reset-author/--author, jj describe --no-edit/--edit/--reset-author/--author
  • Suppression des options jj git push --allow-new, jj metaedit --update-committer-timestamp
  • Suppression des options de configuration obsolètes comme git.auto-local-bookmark, git.push-new-bookmarks
  • jj evolog ne prend plus en charge les prédécesseurs de commits legacy enregistrés avant jj 0.30
  • L’autocomplétion du shell affiche les descriptions des alias personnalisés, revset-alias, template-alias et fileset-alias, et extrait les descriptions depuis le champ .doc des définitions d’alias sous forme de table
  • jj show accepte plusieurs révisions et les affiche dans l’ordre, à la manière de git show
  • jj git fetch génère un historique d’évolution basé sur les change ID et, si le dépôt distant préserve les change ID, rebase les révisions descendantes locales au-dessus des parents réécrits
  • La commande jj util backend name affiche le nom du backend de commit utilisé par le dépôt actuel
  • Ajout du paramètre edit-invocation-mode pour l’éditeur de diff : avec "file-by-file", l’éditeur est exécuté une fois par fichier modifié, ce qui permet d’utiliser des outils par fichier comme vimdiff
  • jj git remote add signale désormais une erreur au lieu de paniquer lorsqu’un nom de remote est vide ou contient des espaces
  • Quand la sortie en couleur est désactivée, le diff color-words affiche l’état before/after sur des lignes séparées, ce qui améliore la lisibilité des diff envoyés dans un pipe ou redirigés

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Lobste.rs

  • Je me demande si, maintenant que jj git fetch génère un historique d’évolution basé sur les change IDs, cela signifie qu’on n’a plus besoin de faire jj new main juste après chaque jj git fetch, à condition que le remote préserve les change IDs
    Si c’est le cas, ça ressemble à une amélioration assez appréciable de la qualité de vie

    • Ce n’est pas comme ça que je le comprends. Après un fetch, il y aura des changes différents d’avant sur main, donc je ne pense pas que ça aide sur ce point
    • Si on ajoute un trailer au message de commit, n’importe quel remote le préserve
      En revanche, je ne sais pas ce qu’il en est des commits de merge générés par GitHub qui n’ont pas de change ID

  • Le point sur le passage à l’allocateur mémoire mimalloc pour améliorer les performances multithread m’intrigue davantage
    Sur des processus de longue durée, j’ai déjà essayé des choses comme jemalloc pour limiter la fragmentation, mais jj donne plutôt l’impression de démarrer en 1 ms et de se terminer en moins de 10 ms, donc c’est surprenant qu’un changement d’allocateur soit perceptible
    En creusant un peu, j’ai trouvé la PR https://github.com/jj-vcs/jj/pull/9484 et à peu près seulement https://github.com/jj-vcs/jj/issues/2490#issuecomment-2595323515, mais ça ne ressemble pas à un énorme gain de vitesse. Cela dit, si c’est plus rapide et que le changement tient en quelques lignes, c’est très bien

  • Il était écrit « si le remote préserve les change IDs », mais je ne sais pas dans quelle mesure les remotes les préservent en général
    Je sais que jj gerrit upload ajoute un footer de change ID, mais un jj git push classique ne le fait pas

    • On peut considérer qu’ils sont préservés tant que les commits ne sont pas réécrits
      En revanche, les opérations qui réécrivent les commits, comme le squash merge de GitHub ou un rebase merge, ne les préservent pas. Avec les outils standard basés sur libgit2, les en-têtes personnalisés ne sont pas conservés, tandis que certains outils comme la bibliothèque Rust utilisée par GitButler prennent en charge la conservation des en-têtes personnalisés, mais je doute que les forges utilisent ce genre d’outils
    • Je me demande quels remotes préservent les change IDs
      Je ne sais même pas comment vérifier qu’ils sont bien préservés
    • Ici, par change ID, il semble qu’on parle non pas du change ID de Gerrit, mais du change ID de jujutsu
      La documentation donne plus de détails
    • GitLab les préserve. C’est comme ça qu’on l’utilise dans mon entreprise en ce moment
      GitHub les préserve aussi ; on peut le voir dans les commits pushcx du code source de lobsters ou dans mes commits

  • Je me demande s’il existe une bonne ressource à lire ou à regarder sur les raisons d’utiliser jj plutôt que Git standard
    Je sais que jj peut fonctionner au-dessus de Git, et j’ai aussi fait quelques essais sur des projets perso, mais je n’arrive toujours pas à trouver l’argument vraiment décisif sur pourquoi ce serait meilleur ou plus simple