• # je ne suis pas d’accord

    Posté par . En réponse au journal Jujutsu v0.44.0. Évalué à 10 (+10/-0).

    J’ai adopté jj il y a un an environ et j’en suis très heureux, mais je ne suis pas d’accord avec " Il est particulièrement simple et intuitif ". Je recommande pas jj à tout le monde, mais à ceux qui connaissent bien git et qui ont compris qu’une branche devrait être immutable seulement si elle est effectivement partagée.

    Je me permet de ressortir, (削除) presque tel quel (削除ここまで) (finalement pas mal réécrit), une description que j’avais fait ailleurs :

    J'utilise jj depuis un an, et pour moi, jj n'est pas mieux, c'est juste différent. jj est un peu plus "sans état" que git. On peut globalement faire les mêmes choses avec les deux.

    Avantage de jj

    les ensembles

    jj propose des options très sophistiquées qui facilitent certains usages. Ce qui nécessiterait un peu de scripting dans git peut souvent être implémenté directement dans jj. Je pense en particulier au fileset et changeset. Vous pouvez facilement sélectionner tous les commits qui touchent vos fichiers *.py ou qui ont un quelque chose dans leur description et faire des opérations ensemblistes dessus. Je veux voir tous les changeset qui modifient des fichier python depuis 1 mois se fait avec :

    jj log -r 'committer_date(after:\"2 months ago\") & files(glob:"**/*.py")'

    la gestion des conflits

    jj ne vous bloque pas en cas de conflits, il marque les commits comme conflictuels et à vous de le corriger quand vous le souhaiter... ou d’annuler ce que vous venez de faire avec un simple undo.

    pas d’état

    Vous n’avez pas besoin de changer continuellement votre HEAD pour manipuler l’historique. Vous pouvez modifier une branche sans être dessus. C’est possible au moins en parti avec git mais il ne vous pousse pas à vous en servir comme le fait jj.

    Avantages de git

    • git a beaucoup plus de documentation, de ressources et d'outils tiers disponibles. Avec jj, on perd presque tous les outils tiers (bien que la colocation git en lecture seule puisse aider).
    • git est stable il ne vous oblige pas à changer des configurations 1 ou 2 fois par an
    • git est supporté partout, jj est en HEAD détaché régulièrement ce que les outils peuvent mal supporter

    Des idée pel-mel de jj qui change pour un utilisateur de git

    • Remplacez 'branch' par 'bookmark' : les deux sont des étiquettes sur les commits, mais les bookmark ne suivent pas HEAD.
    • changeset : les changeset sont au commit ce que les pods sont aux centenaires. Un CS a un id stable qui ne dépend pas de son contenu (il a aussi un id git qui lui dépend du contenu). Un CS a donc son propre historique.
    • Commits immuables : au lieu d'interdire les "force pushes", vous pouvez configurer l'ensemble des commits immuables. Par exemple, trunk() | tags() | ~mine() (tous les commits qui ne sont pas dans le trunk, un tag, ou les miens). Je peux réécrire l'historique uniquement pour les commits mutables, même localement.
    • Je ne sais pas comment ils gèrent le GC, mais les commits n'ont pas besoin d'être dans des branches, donc les stashes peuvent être de simples commits (rappel quand vous commitez, le bookmark n'est pas déplacé).
    • Comme les commits immuables, vous pouvez définir des commits privés (par exemple basés sur les messages de commit, comme s'ils commencent par wip:).
    • rerere est activé par défaut et peut être utilisé immédiatement.
    • Le op log est beaucoup plus facile à utiliser que le reflog.

    Si vous utilisez beaucoup git rebase -i et que passer du temps à configurer aux petits ognons ne vous déplais pas, jj est probablement quelque chose à essayer.

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll