
git-branchless
Dépôt GitHub : https://github.com/arxanas/git-branchless
Journaux liées à cette note :
Journal du mardi 06 mai 2025 à 14:49
Je gère actuellement un projet comprenant 8 Merge Requests empilées (Stacked PRs) en cours de review, s'étendant sur une période d'environ deux mois.
Au fur et à mesure que je continue à travailler sur ce projet, j'ai effectué à plusieurs reprises des améliorations ou des corrections qui concernent des commits déjà en cours de review.
Si ces Merge Request étaient mergés, cela ne me poserait pas de problème. Je proposerai de nouvelles Merge Request avec ces changements.
Dans la situation actuelle, si je souhaite effectuer une amélioration dans la Merge Request numéro 2, je préfère modifier directement cette Merge Request plutôt que d'en créer une nouvelle. Cette approche me semble plus logique et propre, surtout pour une Merge Request qui n'a pas encore été review.
En pratique, la modification de la Merge Request numéro 2 est une tâche fastidieuse. Si je modifie cette Merge Request, je vais devoir propager mon changement sur 6 branches et résoudre de nombreux conflits. J'ai peur de faire une erreur.
Cette opération est très pénible.
C'est pour cette raison que j'ai étudié dernièrement Stacked Git et Jujutsu.
Je me demande quel outil serait le plus adapté pour gérer ma problématique.
git-stack, git-branchless, Stacked Git ou Jujutsu 🤔.
Journal du mardi 06 mai 2025 à 13:42
Suite à la lecture du thread "jj tips and tricks" Lobster, je suis tombé dans un rabbit hole (1h30) : #JaiLu les articles ci-dessous au sujet de Jujutsu.
- "What I've learned from jj" (134 commentaires Hacker News et 57 commentaires Lobster)
- Et ses sous-articles :
- "jj tips and tricks"
Quelques commentaires au sujet de l'article "What I've learned from jj"
Along with describing and making new changes, jj squash allows you to take some or all of the current change and “squash” it into another revision. This is usually the immediate parent, but can be any revision.
...
With jj squash, the current change is pushed into whatever target revision you want. And if that change has children, they’ll all be automatically rebased to incorporate the updated code, no additional work is needed.
J'ai hâte de tester si, à l'usage, c'est sensiblement plus simple qu'avec Git 🤔.
Conflict resolution
One of the consequences of being able to modify changes in-place is that all subsequent changes need to be rebased to account for the updated parent. If there were a sequence
s -> t -> u -> v
and you’d modifiedt
, jj will automatically rebase the rest:s -> t' -> u' -> v'
. This includes conflicts, if any arise. The difference from git is that conflicts are not a stop-the-world event! You’ll see in the jj log output that changes have a conflict, but it won’t prevent a command (like an explicit or implicit rebase) from running to completion. You get to choose when and how to resolve the conflicts afterward. I found this a surprising benefit: rebases are already less stressful because of how easyundo
is, but now I’m no longer interrupted and forced to resolve conflicts immediately.
Cette simplicité annoncée me surprend vraiment. J'ai du mal à imaginer le fonctionnement, sans doute parce que je suis trop habitué à utiliser Git. J'ai l'impression que c'est de la magie !
J'ai hâte de tester !
... efforts to add
Change-ID
as a supported header in git itself to enable durable change tracking on top of commits.
J'ai découvert cette initiative, je trouve cela très intéressant👌.
Un commentaire au sujet de l'article "First-class conflicts"
First-class conflicts
...
Unlike most other VCSs, Jujutsu can record conflicted states in commits. For example, if you rebase a commit and it results in a conflict, the conflict will be recorded in the rebased commit and the rebase operation will succeed. You can then resolve the conflict whenever you want. Conflicted states can be further rebased, merged, or backed out. Note that what's stored in the commit is a logical representation of the conflict, not conflict markers; rebasing a conflict doesn't result in a nested conflict markers (see technical doc for how this works).
Je trouve cela très intéressant.
Voici une commande pour extraire un patch avec l'inclusion des "Conflict markers" (je n'ai pas encore testé) :
$ jj diff --include-conflicts > conflicts.patch
Un commentaire au sujet de l'article "In Praise of Stacked PRs"
“Stacked PRs” is the practice of breaking up a large change into smaller, individually reviewable PRs which can depend on each other, forming a DAG.
Je suis ravi de découvrir que le terme "Stacked PRs" existe pour décrire le concept que j'expliquais souvent quand j'étais chez Spacefill.
En lisant ces articles, #JaiDécouvert :
git-rerere
- Mercurial Changset Evolution
git-machete
- git-stack (
git-stack
) - GitBulter (https://github.com/gitbutlerapp/gitbutler)
et j'ai "redécouvert" :
Journal du samedi 07 décembre 2024 à 19:04
En travaillant sur Projet 19, #JaiDécouvert le projet git-branchless (https://github.com/arxanas/git-branchless).
High-velocity, monorepo-scale workflow for Git.
Je n'ai pas encore compris à quoi cela sert.