Git

#version-control-system

Ressouces :

Writing commit messages/

Journaux liées à cette note :

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.

source

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 modified t, 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 easy undo is, but now I’m no longer interrupted and forced to resolve conflicts immediately.

source

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.

source

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).

source

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.

source

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 :

et j'ai "redécouvert" :

git-branchless git-branchless

#JeSouhaiteLire :

Depuis un an que j'effectue des missions Freelance, j'ai régulièrement besoin d'effectuer des changements dans des projets pour intégrer mes pratiques development kit, telles que l'utilisation de Mise, .envrc, docker-compose.yml, un README guidé, etc.

Généralement, ces missions Freelance sont courtes et je ne suis pas missionné pour faire des propositions d'amélioration de l'environnements de développement.

En un an, j'ai été confronté à cette problématique à cinq reprises.

Jusqu'à présent, j'ai utilisé la méthode suivante :

J'ai intégré mon development kit dans une branche sklein-devkit
Cette branche m'a ensuite servi de base pour créer des branches destinées à traiter mes issues, nommées sous la forme sklein-devkit-issue-xxx
Et pour finir, je transfère mes commits avec git cherry-pick dans une branche du type issue-xxx que je soumettais dans une Merge Request ou Pull Request.

À la base, ce workflow de développement n'est pas très agréable à utiliser, et devient particulièrement complexe lorsque je dois effectuer des git pull --rebase sur la branche sklein-devkit !

Dans les semaines à venir, pour le projet Albert Conversation, je dois trouver une solution élégante pour gérer un cas similaire. Il s'agit de maintenir des modifications (série de patchs) du projet https://github.com/open-webui/open-webui qui :

seront soit intégrées au projet upstream après plusieurs semaines ou mois
soit resteront spécifiques au projet Albert Conversation et ne seront jamais intégrées en upstream, comme par exemple l'intégration du Système de Design de l'État.

Je me souviens avoir été marqué par l'histoire du projet Real-Time Linux mentionnée dans l'épisode 118 du podcast de Clever Cloud : les développeurs de Real-Time Linux ont maintenu pendant 20 ans toute une série de patchs avant de finir par être intégrés dans le kernel upstream (source : la conférence "PREEMPT_RT over the years") !

Voici la liste des patchs maintenus par l'équipe Real-Time Linux :

└── patches
    ├── 0001-arm-Disable-jump-label-on-PREEMPT_RT.patch
    ├── 0001-ARM-vfp-Provide-vfp_state_hold-for-VFP-locking.patch
    ├── 0001-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
    ├── 0001-hrtimer-Use-__raise_softirq_irqoff-to-raise-the-soft.patch
    ├── 0001-powerpc-Add-preempt-lazy-support.patch
    ├── 0001-sched-Add-TIF_NEED_RESCHED_LAZY-infrastructure.patch
    ├── 0002-ARM-vfp-Use-vfp_state_hold-in-vfp_sync_hwstate.patch
    ├── 0002-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
    ├── 0002-locking-rt-Remove-one-__cond_lock-in-RT-s-spin_trylo.patch
    ├── 0002-powerpc-Large-user-copy-aware-of-full-rt-lazy-preemp.patch
    ├── 0002-sched-Add-Lazy-preemption-model.patch
    ├── 0002-timers-Use-__raise_softirq_irqoff-to-raise-the-softi.patch
    ├── 0002-tracing-Record-task-flag-NEED_RESCHED_LAZY.patch
    ├── 0003-ARM-vfp-Use-vfp_state_hold-in-vfp_support_entry.patch
    ├── 0003-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
    ├── 0003-locking-rt-Add-sparse-annotation-for-RCU.patch
    ├── 0003-riscv-add-PREEMPT_LAZY-support.patch
    ├── 0003-sched-Enable-PREEMPT_DYNAMIC-for-PREEMPT_RT.patch
    ├── 0003-softirq-Use-a-dedicated-thread-for-timer-wakeups-on-.patch
    ├── 0004-ARM-vfp-Move-sending-signals-outside-of-vfp_state_ho.patch
    ├── 0004-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
    ├── 0004-locking-rt-Annotate-unlock-followed-by-lock-for-spar.patch
    ├── 0004-sched-x86-Enable-Lazy-preemption.patch
    ├── 0005-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
    ├── 0005-sched-Add-laziest-preempt-model.patch
    ├── 0006-drm-i915-Drop-the-irqs_disabled-check.patch
    ├── 0007-drm-i915-guc-Consider-also-RCU-depth-in-busy-loop.patch
    ├── 0008-Revert-drm-i915-Depend-on-PREEMPT_RT.patch
    ├── 0053-serial-8250-Switch-to-nbcon-console.patch
    ├── 0054-serial-8250-Revert-drop-lockdep-annotation-from-seri.patch
    ├── Add_localversion_for_-RT_release.patch
    ├── ARM__Allow_to_enable_RT.patch
    ├── arm-Disable-FAST_GUP-on-PREEMPT_RT-if-HIGHPTE-is-als.patch
    ├── ARM__enable_irq_in_translation_section_permission_fault_handlers.patch
    ├── netfilter-nft_counter-Use-u64_stats_t-for-statistic.patch
    ├── POWERPC__Allow_to_enable_RT.patch
    ├── powerpc_kvm__Disable_in-kernel_MPIC_emulation_for_PREEMPT_RT.patch
    ├── powerpc_pseries_iommu__Use_a_locallock_instead_local_irq_save.patch
    ├── powerpc-pseries-Select-the-generic-memory-allocator.patch
    ├── powerpc_stackprotector__work_around_stack-guard_init_from_atomic.patch
    ├── powerpc__traps__Use_PREEMPT_RT.patch
    ├── riscv-add-PREEMPT_AUTO-support.patch
    ├── sched-Fixup-the-IS_ENABLED-check-for-PREEMPT_LAZY.patch
    ├── series
    ├── sysfs__Add__sys_kernel_realtime_entry.patch
    └── tracing-Remove-TRACE_FLAG_IRQS_NOSUPPORT.patch

46 files

J'ai été impressionné, je me suis demandé comment cette équipe a réuissi à gérer ce projet aussi complexe sur une si longue durée sans finir par se perdre !

Real-Time Linux n'est pas le seul projet qui propose des versions patchées du kernel, c'est le cas aussi du projet Xen, Openvz, etc.

J'ai essayé de comprendre le workflow de développement de ces projets. Avec l'aide de Claude.ia, il semble que ces projets utilisent un outil comme quilt qui permet de gérer des séries de patchs.

Il semble aussi que Debian utilise quilt pour gérer des patchs ajoutés aux packages :

Quilt has been incorporated into dpkg, Debian's package manager, and is one of the standard source formats supported from the Debian "squeeze" release onwards.

source

J'ai creusé un peu de sujet et à l'aide de Claude.ia j'ai découvert des alternatives "modernes" à quilt.

Git lui-même :
- git format-patch pour créer des séries de patches
- git am pour appliquer des patches
- git range-diff pour comparer des séries de patches
- Branches de fonctionnalités + git rebase -i pour organiser les commits
Stacked Git (https://stacked-git.github.io/) :
- Conçu spécifiquement comme une alternative moderne à Quilt
- S'intègre mieux avec Git
- Maintient une pile de patches comme Quilt mais dans l'écosystème Git
Topgit (https://github.com/mackyle/topgit) :
- Gère des changements de code sous forme de piles (stacks)
- Permet de maintenir des patches à long terme pour des forks
Git Patchwork - (https://github.com/getpatchwork/patchwork) :
- Système de gestion et suivi des patches envoyés par email
- Utilisé par le noyau Linux et d'autres projets open source
Guilt (http://repo.or.cz/w/guilt.git) :
- Clone de Quilt implémenté comme scripts Git
- Intégration très proche de Git
Jujutsu :
- Système de contrôle de version moderne basé sur Git
- Meilleure gestion des branches et séries de patches
Git Series (https://github.com/git-series/git-series) :
- Outil pour travailler avec des séries de patches Git
- Permet de suivre l'évolution des séries au fil du temps

Après avoir jeté un œil sur chacun de ces projets, j'envisage de créer un playground pour tester Stacked Git.

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.

La fonctionnalité "Activité" de GitLab me manque dans GitHub.

Voici trois exemples concrets de fonctionnement de cette fonctionnalité, dans trois contextes différents.

Le premier, dans le projet GNOME Shell :

Le second, dans le groupe Wayland : https://gitlab.freedesktop.org/groups/wayland/-/activity

Et le troisième, pour l'utilisateur Lucas Stach: https://gitlab.freedesktop.org/users/lynxeye/activity

Je trouve cette fonctionnalité très utile quand on travaille sur un projet. Elle permet d'avoir une vue d'ensemble de ce qui s'est passé sur un projet sur une période. Elle vient en complément de l'historique Git qui est limité aux changements effectués sur le code source.

Dans certaines situations, je sais qu'un collègue travaille sur un sujet qui me concerne et la fonctionnalité "Activité" me permet de mieux comprendre où il en est, de suivre facilement ce qu'il fait.

Cette fonctionnalité "Activité" permet de pratiquer la stigmergie.

J'utilise aussi cette fonctionnalité lors de la rédaction d'un rapport d'activité ou d'un message de Daily Scrum. Elle m'aide à retrouver précisément ce que j'ai fait dernièrement.

Je trouve la page "Contribution activity" d'un user GitHub limité, par exemple, elle ne contient pas l'historique des commentaires.

Même chose au niveau d'un projet, dans la page "Pulse", par exemple : https://github.com/sveltejs/kit/pulse.

Je viens de regarder du côté de Codeberg / Forgejo : <https://codeberg.org/forgejo/forgejo/activity. Même constat que pour GitHub, les informations sont très réduites.

#JaiDécouvert ce guide pour Git : Flight rules for Git.

Je le trouve excellent 👌.

Et voici une autre article intéressant au sujet de Git rebase : git rebase in depth.