L'auteur est passé de Vim/Neovim à Helix, un éditeur de texte, attiré par la facilité d'intégration des serveurs de langage. Après des années de lutte avec des configurations Vim complexes, les fonctionnalités intégrées d'Helix étaient attrayantes. Les fonctionnalités de recherche et de référence rapide d'Helix sont particulièrement utiles et appréciées. L'auteur s'est facilement adapté aux raccourcis clavier d'Helix, bien que certaines habitudes Vim aient nécessité des ajustements. L'auteur a trouvé les curseurs multiples et le changement de tampon d'Helix préférables aux macros et aux onglets de Vim. Cependant, l'auteur note quelques désagréments, notamment des problèmes de retour à la ligne avec les listes et l'absence d'annulation persistante et de rechargement automatique. Malgré ces frustrations, l'auteur s'est adapté à Helix, trouvant la transition plus facile que prévu. La configuration simple de l'éditeur est un avantage majeur par rapport aux complexités de sa configuration précédente. L'auteur utilise principalement Helix dans un terminal, organisant ses projets avec des fenêtres dédiées. L'auteur est satisfait d'Helix après trois mois d'utilisation, mais reste ouvert à un éventuel retour à Vim.

L'auteur a publié un nouveau zine intitulé "The Secret Rules of the Terminal" (Les règles secrètes du terminal) qui explique le fonctionnement du terminal et propose des conseils et astuces pour utiliser les programmes en ligne de commande. L'auteur utilise le terminal quotidiennement depuis 20 ans, mais avait encore de nombreuses incompréhensions sur son fonctionnement. Le terminal présente de nombreuses petites incohérences, comme parfois permettre l'utilisation des touches fléchées pour se déplacer et parfois non. Les "règles" du fonctionnement du terminal sont difficiles à comprendre car il est composé de nombreux logiciels différents. Le zine explique comment les quatre composantes du terminal (shell, émulateur de terminal, programmes et pilote TTY) s'articulent et présente les conventions fondamentales du fonctionnement du terminal. L'auteur a beaucoup appris en écrivant le zine, notamment comment configurer son shell et comprendre les codes d'échappement. Le zine est disponible à l'achat en version PDF ou imprimée, et un lot de 15 zines de l'auteur est également proposé. L'auteur a reçu l'aide de nombreuses personnes, dont un réviseur technique qui a écrit PuTTY et une personne qui comprend le fonctionnement interne du terminal. La version imprimée sera expédiée en août, et l'auteur doit attendre les commandes pour déterminer le nombre d'exemplaires à imprimer. Le zine est disponible pour 12 $, et l'auteur espère qu'il aidera les lecteurs à mieux comprendre et utiliser le terminal.

L'auteur n'est pas un programmeur C, mais a parfois besoin de compiler des programmes C/C++ à partir du code source. Auparavant, ils comptaient sur d'autres pour compiler les programmes, mais depuis qu'ils sont passés à un Mac, ils ont dû apprendre à compiler les programmes eux-mêmes. Pour compiler un programme C, il faut installer un compilateur C, installer les dépendances du programme, exécuter ./configure si nécessaire, et exécuter make. L'auteur explique comment installer un compilateur C, installer les dépendances, et exécuter ./configure. Ils abordent également les problèmes courants qui peuvent survenir pendant le processus de compilation, tels que les problèmes de dépendances et les erreurs de compilation. L'auteur explique comment résoudre ces problèmes en passant des drapeaux (flags) au compilateur et à l'éditeur de liens (linker). Ils donnent également des conseils sur la manière de compiler des fichiers spécifiques, d'examiner comment d'autres systèmes de packaging ont compilé le même programme C, et d'installer le binaire. L'auteur conclut qu'il est utile de comprendre les bases du fonctionnement des programmes C, même si l'on n'est pas un programmeur C.

Les programmes dans le terminal se comportent de manière cohérente malgré l'absence de normes. Ils suivent certaines règles, comme les programmes non interactifs qui s'arrêtent lorsque l'on appuie sur Ctrl-C, les TUI qui s'arrêtent lorsque l'on appuie sur 'q', et les REPL qui s'arrêtent lorsque l'on appuie sur Ctrl-D sur une ligne vide. La plupart des programmes prennent en charge les raccourcis clavier readline, désactivent les couleurs lors de l'écriture dans un tube, et utilisent '-' pour signifier stdin/stdout. Ces règles sont descriptives, et non prescriptives, et comprendre ces règles aide à utiliser les programmes de terminal de manière efficace.

"Le tamponnage est courant dans les programmes de terminal pour améliorer les performances en regroupant la sortie jusqu'à ce qu'un certain seuil de taille soit atteint. Cela peut causer des problèmes lorsque les données sont ajoutées lentement à un tube, car les programmes peuvent tamponner leur sortie et jamais l'écrire. Grep et des programmes similaires utilisent par défaut le tamponnage par blocs lors de l'écriture dans des tubes, mais utilisent le tamponnage par lignes lors de l'écriture dans les terminaux, ce qui explique pourquoi la commande "tail -f /some/log/file | grep thing1 | grep thing2" peut ne pas afficher de sortie. Plusieurs commandes tamponnent leur sortie, y compris grep, sed, awk, tcpdump et jq, tandis que les commandes comme tail, cat et tee ne le font pas. Les langages de programmation comme C, Python, Ruby et Perl peuvent également tamponner la sortie, avec diverses méthodes pour désactiver le tamponnage. Lorsque Ctrl-C est pressé sur un tube, le buffer de sortie du programme peut être perdu, car le signal est reçu avant que le buffer ne puisse être vidé. Le tamponnage se produit également lors de la redirection vers un fichier, mais il se comporte généralement comme attendu, avec le contenu du buffer étant écrit avant que le programme ne se termine. Pour éviter le tamponnage, on peut exécuter un programme qui se termine rapidement, utiliser le drapeau "--line-buffered" avec grep, réécrire la commande en utilisant awk, utiliser stdbuf, ou utiliser unbuffer pour forcer le programme à se comporter comme s'il écrivait dans un terminal. La solution idéale dépend de la situation spécifique, avec unbuffer étant un choix fiable pour son comportement cohérent. Bien que le tamponnage ne soit généralement pas un problème courant, il peut survenir lorsque les données sont ajoutées lentement à un tube. Une variable d'environnement pour désactiver le tamponnage pourrait être utile, mais sa conception et sa mise en œuvre présentent des défis."

L'auteur préfère écrire du JavaScript sans système de construction et partage son expérience d'importation de bibliothèques sans utiliser de système de construction. Il explique les trois principaux types de fichiers JavaScript qu'une bibliothèque peut fournir : des fichiers de variables globales "classiques", des modules ES et des modules CommonJS. L'auteur montre comment trouver les fichiers dans une construction NPM d'une bibliothèque et discute de l'utilisation de cartes d'importation pour utiliser des modules ES dans le navigateur. Il mentionne également l'utilisation d'esm.sh pour convertir des modules CommonJS en modules ES. L'auteur fournit des exemples d'utilisation de Chart.js, @atcute/oauth-browser-client et @atproto/oauth-client-browser, en discutant des différentes approches pour chacun. Il note que l'utilisation de cartes d'importation nécessite une prise en charge du navigateur, ce qui peut être une préoccupation pour les anciens navigateurs. L'auteur mentionne également l'utilisation d'esbuild comme alternative aux cartes d'importation. Enfin, il résume les trois types de fichiers JavaScript et explique comment les identifier et les utiliser.

L'auteur a créé une nouvelle section sur son site intitulée "TIL" (Today I Learned, Aujourd'hui j'ai appris) pour y enregistrer les outils et les faits intéressants qu'il publie sur les réseaux sociaux. L'objectif est de disposer d'un endroit pour stocker ces informations sans avoir à écrire un article de blog complet. L'auteur publie souvent des "choses cool" sur Mastodon et Bluesky, mais il n'avait pas d'endroit pour les garder en mémoire. Cette nouvelle section est inspirée du blog TIL de Simon Willison, mais les publications de l'auteur sont beaucoup plus courtes. L'auteur a créé un nouveau dossier pour la section TIL, ajouté un style personnalisé et configuré un flux RSS séparé. La section TIL est principalement destinée à un usage personnel, comme un moyen de suivre les liens et les outils utiles. L'auteur utilise cette section depuis quelques semaines et a constaté qu'elle fonctionne bien. L'auteur est un fan de l'idée "POSSE" (publier sur son propre site, syndiquer ailleurs), mais il trouve plus facile d'identifier les catégories spécifiques de contenu qu'il souhaite conserver sur son propre site. L'auteur possède des listes de diffusion et des flux RSS pour ses articles de blog et ses bandes dessinées, et il pourrait ajouter un résumé des publications TIL à sa liste de diffusion. L'auteur préfère garder certains contenus éphémères, comme les sondages et les blagues, et n'archive que les catégories spécifiques de contenu.

L'auteur explore le concept de codes de contrôle dans le terminal, tels que Ctrl-A, Ctrl-C et Ctrl-W, et leur fonctionnement. Il existe 33 caractères de contrôle ASCII, qui peuvent être catégorisés en codes gérés par le pilote de terminal du système d'exploitation, codes correspondant à des pressions de touches littérales et codes utilisés par readline. L'auteur note qu'il n'y a pas de structure réelle pour déterminer quels codes sont dans quelle catégorie, car ils ont évolué de manière organique. Il n'y a que 33 codes de contrôle, ce qui signifie que si vous voulez utiliser Ctrl-1 comme raccourci clavier, cela n'a pas de sens, car c'est la même chose que de presser 1. L'auteur note également que Ctrl+Maj+C n'est pas un code de contrôle et que son comportement dépend de l'émulateur de terminal. Les noms officiels ASCII pour les codes de contrôle ne sont pas très utiles, car ils ont été initialement définis pour les machines à télégraphe et ont depuis été réaffectés. L'auteur trouve difficile d'utiliser Ctrl-M et Ctrl-I comme raccourcis clavier, car ils sont équivalents à Entrée et Tabulation, respectivement. L'auteur fournit un script Python pour identifier quels codes de contrôle sont envoyés lors de la pression de différentes combinaisons de touches. L'auteur note que certains codes de contrôle, tels que Ctrl-W et Ctrl-U, peuvent être gérés différemment en fonction de si le terminal est en mode canonique ou non canonique. Enfin, l'auteur reconnaît qu'il y a de nombreux cas particuliers et conflits lorsqu'il s'agit de codes de contrôle, et que toutes ces informations ne sont pas nécessairement utiles en pratique.

L'auteur de Mess With DNS rencontrait des problèmes avec le programme qui consommait trop de mémoire et était tué par le gestionnaire de mémoire (OOM), ce qui causait des problèmes avec le script de sauvegarde. Pour résoudre cela, l'auteur a décidé d'essayer de faire en sorte que Mess With DNS consomme moins de mémoire. Le programme charge une base de données d'adresses IP en mémoire, ce qui utilisait environ 117 Mo de mémoire. L'auteur a essayé trois approches différentes pour réduire l'utilisation de la mémoire. La première approche consistait à utiliser SQLite pour stocker les données sur disque, ce qui a résolu le premier objectif de mémoire mais a rencontré des problèmes pour stocker les adresses IPv6 et était 500 fois plus lent que la recherche binaire originale. La deuxième approche consistait à utiliser un trie, mais elle utilisait plus de mémoire et était plus lente que la recherche binaire originale. La troisième approche consistait à faire en sorte que le tableau utilise moins de mémoire en dédupliquant les champs Name et Country, ce qui a réduit l'utilisation de la mémoire de 117 Mo à 65 Mo, puis en passant à netip.Addr au lieu de net.IP, ce qui a économisé 20 Mo de mémoire supplémentaires, portant le total à 46 Mo. L'auteur a pu économiser 70 Mo de mémoire au total.

L'auteur du billet de blog a décidé de mettre à niveau sa version de Hugo de 0.40 à 0.135, malgré le bon fonctionnement de l'ancienne version. Il a documenté les changements qu'il a dû effectuer pendant le processus de mise à niveau, notamment le remplacement des appels de modèle, la mise à jour des références de page et l'inversion du sens de « suivant » et « précédent » dans son thème. L'auteur a également dû mettre à jour ses fichiers Markdown pour qu'ils fonctionnent avec le nouveau moteur de rendu Goldmark, qui a remplacé l'ancien moteur de rendu Blackfriday. Cela impliquait de modifier la façon dont il écrivait Markdown, notamment en mélangeant HTML et Markdown, en utilisant des guillemets et en mettant en retrait les listes imbriquées. L'auteur a également dû configurer le moteur de rendu Goldmark pour désactiver la coloration syntaxique et utiliser l'ancienne méthode pour générer les ID d'en-tête. Il a écrit un script pour comparer la sortie des moteurs de rendu Blackfriday et Goldmark et l'a utilisé pour identifier et corriger les problèmes de ses fichiers Markdown. L'auteur note que le processus de mise à niveau a pris du temps et a présenté des difficultés, mais estime finalement que cela valait la peine d'avoir un moteur de rendu Markdown plus évolutif. Il mentionne également qu'il devra probablement effectuer des changements similaires lors de la mise à niveau de son autre site, wizardzines.com, qui utilise toujours une ancienne version de Hugo.

Fish est un shell populaire qui offre une expérience utilisateur améliorée avec plusieurs fonctionnalités clés. Ces fonctionnalités comprennent des suggestions d'historique automatiques, une auto-complétion intelligente, une insertion facile de commandes multi-lignes, une interface de complétion de tabulation conviviale et un prompt par défaut bien conçu avec intégration Git. Fish bénéficie également d'un système d'historique exhaustif avec une fonction de recherche et évite la rupture du terminal due à l'envoi accidentel de données binaires. Il désactive la combinaison de touches Ctrl+S potentiellement perturbatrice, propose une utilité de modification de chemin global et offre une mise en évidence de la syntaxe pour les commandes inexistantes. De plus, Fish offre une syntaxe de boucle simplifiée, une édition multi-ligne facilitée et des raccourcis clés Ctrl+gauche/droite pour la navigation par mots. Bien qu'il puisse y avoir des instructions limitées pour l'intégration de certains outils avec Fish, il est devenu plus largement accepté, et les utilisateurs peuvent recourir aux shells POSIX quand cela est nécessaire. Fish est particulièrement adapté aux personnes qui privilégient une configuration minimale, apprécient ses paramètres par défaut et souhaitent un shell avec un design intuitif et riche en fonctionnalités.

Jouer avec DNS est une plateforme d'apprentissage de la fonctionnalité DNS en créant et en éditant des enregistrements. La mise en œuvre originale du DNS avait des limitations, y compris des noms de domaine interdits avec des tirets, absence de support pour les enregistrements CNAME, et absence de types d'enregistrements SVCB et HTTPS. Pour résoudre ces problèmes, l'auteur a intégré PowerDNS, un serveur DNS open source avec une API HTTP, remplaçant la précédente mise en œuvre du DNS. Cela a présenté des défis pour intercepter les requêtes DNS et concevoir une API qui répondait aux besoins du frontend. Pour la gestion des erreurs, l'auteur a adapté les messages d'erreur pour les utilisateurs pour fournir des informations plus claires, en gérant les réponses d'erreur de l'API PowerDNS et en effectuant une validation d'entrée basique. SQLite a remplacé Postgres pour la gestion de la base de données en raison de kills OOM (Out of Memory) expérimentés avec Postgres. La bibliothèque Vue.js a été mise à jour vers la version 3, accompagnée d'une transition vers l'utilisation d'outils de validation de formulaire intégrés au navigateur et de la mise en œuvre d'un magasin d'état global pour la gestion frontend. Le projet a été divisé en phases pour une mise en œuvre gérable, y compris la mise à jour de Vue, la création d'un magasin d'état, la révision de l'API backend et l'intégration de PowerDNS. Le site web mis à jour a été publié et fonctionne bien, résolvant les problèmes DNS précédemment signalés par les utilisateurs.

L'auteur, un programmeur Go occasionnel, a rencontré un bug qui a révélé une méconception fondamentale de la manière dont les structs sont copiés pendant l'attribution en Go. Cette méconception provenait du fait que les structs sont copiés à l'attribution, et non référencés, ce qui a conduit à un comportement inattendu lors de la modification d'un struct après l'avoir attribué à une autre variable. L'auteur a été surpris par ce comportement, car son expérience avec d'autres langages l'avait amené à croire que les variables étaient généralement passées par référence. Cette erreur de conception a été encore compliquée par la compréhension de l'auteur sur le passage par valeur et le passage par référence dans les arguments de fonction, qu'il n'avait pas étendu aux attributions de variables. L'auteur a également découvert que les sous-tranches dans Go partagent le même tableau de base que la tranche originale, ce qui signifie que l'ajout à une sous-tranche peut modifier involontairement la tranche originale. En outre, l'auteur a acquis une clarté sur la différence entre les récepteurs de valeur et les récepteurs de pointeur dans les méthodes Go, comprenant que les récepteurs de pointeur sont nécessaires lorsque une méthode doit modifier le struct sur lequel elle est appelée. L'auteur a également loué la ressource "100 Go Mistakes" pour son format clair et concis, qui lui a permis d'identifier et d'apprendre rapidement des pièges courants en Go. Enfin, l'auteur a énuméré d'autres ressources Go précieuses, y compris "Go by Example", "go.dev/play" et des outils d'analyse statique comme "staticcheck" et "golangci-lint."

Saisir du texte dans le terminal peut être difficile en raison d'incohérences entre les programmes. Des fonctionnalités de base comme les touches fléchées ne sont pas toujours prises en charge. Readline, une bibliothèque offrant des capacités d'édition de texte, est largement utilisée et prend en charge divers raccourcis clavier. Les programmes sans support readline peuvent être améliorés en utilisant rlwrap. Certains programmes utilisent des systèmes d'entrée personnalisés qui imitent readline ou offrent des fonctionnalités supplémentaires. Comprendre le système d'entrée utilisé peut améliorer la prévisibilité. Des raccourcis courants incluent Ctrl+A pour le début de la ligne, Ctrl+E pour la fin, et Ctrl+R pour la recherche dans l'historique. De nombreux shells prennent en charge les raccourcis clavier vi comme mode d'entrée alternatif. Diagnostiquer le système d'entrée (aucun système d'entrée, readline ou personnalisé) permet d'utiliser de manière ciblée les fonctionnalités disponibles. Cependant, il y a des complexités supplémentaires liées à la saisie de texte dans le terminal qui ne sont pas couvertes dans ce résumé.

La gestion des travaux est une fonctionnalité dans votre shell qui permet de gérer les processus en les déplaçant entre trois états : premier plan, arrière-plan et arrêté. Elle inclut des commandes comme fg, bg, Ctrl+z, jobs, kill, disown et wait. Fish, bash et zsh prennent tous en charge la gestion des travaux, mais elle peut être utilisée différemment dans chaque shell. Certains préfèrent la gestion des travaux à l'utilisation des onglets de terminal car ils aiment voir tous leurs terminaux à l'écran en même temps. Elle peut être utile pour tuer les processus qui ne répondent pas à Ctrl+C, exécuter des applications GUI ou des programmes gourmands en CPU en arrière-plan, et pour configurer des variables d'environnement pour plusieurs commandes. La gestion des travaux peut également être nécessaire dans des situations où vous êtes en mode utilisateur unique ou connecté via SSH à une machine sans tmux ou screen.

"Comment Git fonctionne" est un nouveau zine de Julia Evans qui vise à démystifier Git, un système de gestion de versions populaire. Le zine cible les utilisateurs qui ont des années d'expérience avec Git mais qui ont encore du mal à le maîtriser, en cherchant à clarifier les conceptions erronées courantes et à offrir une compréhension plus profonde de sa logique interne. Evans reconnaît la nature confuse de la terminologie de Git, des messages d'erreur et du comportement incohérent, mais souligne que gérer ces écueils devient routinier avec l'expérience. Le zine se concentre sur le comportement de l'interface utilisateur et sur la manière dont il se rapporte aux processus Git internes, évitant de mettre trop l'accent sur les internals. Il comprend également une feuille de triche imprimable et un transcript HTML pour l'accessibilité. Malgré de mettre en évidence les complexités de Git, Evans reste enthousiaste quant à l'outil, appréciant sa rapidité, sa compatibilité descendante et la disponibilité d'options d'hébergement gratuites. La création du zine a impliqué la collaboration avec diverses personnes, y compris Marie Claire LeBlanc Flanagan pour des explications claires, Vladimir Kašiković pour la conception de la couverture et 66 beta-lecteurs pour les retours. Le zine est disponible à l'achat en PDF ou en version imprimée, avec des commandes d'impression qui seront expédiées en juillet.

Les messages d'erreur Git peuvent être confusants, en particulier pour les débutants. L'auteur examine plusieurs messages d'erreur courants, mettant en évidence leurs complexités et offrant des solutions pratiques. Un défi pour améliorer ces messages est la difficulté à déterminer si les changements sont réellement bénéfiques. L'auteur note que la maintenance de Git est complexe, impliquant des facteurs tels que la traduction internationale et le financement limité pour les efforts d'amélioration. Cependant, certaines suggestions pour améliorer les messages d'erreur incluent la fourniture de distinctions plus claires entre les branches divergentes et celles qui sont en retard, et la réduction du nombre écrasant d'options présentées aux utilisateurs lors de la réconciliation de branches divergentes. De plus, l'auteur souligne l'importance de comprendre la logique interne de Git, comme la différence entre les branches et les chemins dans le contexte de commandes comme `git checkout`. En comprenant ces nuances, les utilisateurs peuvent mieux interpréter les messages d'erreur et naviguer efficacement dans l'interface de ligne de commande de Git.

L'auteur a expérimenté des hobbies non informatiques, y compris la crochet de petits cactus. Ils partagent leurs expériences, y compris les modèles, les types de fil et les techniques qu'ils ont utilisés. Initialement en utilisant des modèles gratuits, ils préfèrent maintenant acheter des modèles pour soutenir les créateurs. Ils mettent en avant le plaisir de modifier les modèles et d'embrasser les erreurs comme des opportunités d'apprentissage. Au lieu d'yeux de sécurité, ils brodent des yeux et utilisent des bouts de fil comme marqueurs de points pour simplifier le processus. L'auteur a du mal à compter en crochet, mais trouve des moyens de surmonter cela en inspectant visuellement et en approximant. Ils ont exploré divers poids de fil et marques, expérimentant avec le mérinos, le coton et l'acrylique. La taille du crochet semble moins conséquente pour les projets de cactus. L'auteur a appris les points de base et aborde les nouveaux points en commençant des modèles et en cherchant des conseils sur des vidéos YouTube. Ils ont créé des éléments tels qu'un éléphant, des cactus et une souris en cours. L'auteur apprécie la nature tactile de la crochet, l'aspect social et l'espace minimal requis pour les matériaux. Ils soulignent le pardon de la crochet, permettant l'expérimentation et l'acceptation des erreurs.

L'auteur a organisé des sondages sur Mastodon pour recueillir des informations sur la manière dont les gens utilisent et perçoivent Git, révélant des constatations surprenantes. La stratégie de fusion la plus courante est "merge", avec seulement 30% utilisant "rebase" fréquemment. Malgré des conflits occasionnels, seuls 14% ont perdu du travail en raison de problèmes Git au cours des dernières années. Beaucoup d'utilisateurs ne connaissent pas les termes comme "HEAD", "ref" et "fast-forward", incitant l'auteur à utiliser ces termes avec prudence. Il est intéressant de noter que la plupart préfèrent Git à SVN, et il y a une préférence partagée entre Git et Mercurial. Notamment, 71% des utilisateurs affichent leur branche actuelle dans leur invite de shell. L'auteur partage les résultats des sondages sur les concepts Git tels que les commits, les branches et l'environnement Git, offrant des informations précieuses sur les perceptions et les préférences des utilisateurs.

Le concept de 'branche actuelle' dans Git, bien qu'apparemment simple, présente une certaine ambiguïté lorsqu'il est examiné de près. Alors que le glossaire Git le définit comme le contenu du fichier .git/HEAD, d'autres interprétations existent, y compris la sortie de "git status", la dernière branche vérifiée et la invite de shell. Ces interprétations s'alignent souvent mais divergent dans des scénarios spécifiques comme les états de tête détachés, les balises vérifiées et les situations de rebase en cours. Par exemple, la vérification d'une balise entraîne le stockage de l'ID de commit dans .git/HEAD tandis que "git status" affiche le nom de la balise pour convenance utilisateur. De même, pendant un rebase, "git status" met en évidence l'état de rebase tandis que l'invite de shell peut indiquer la branche d'origine. Même "git init" introduit une nuance où la "branche actuelle" est automatiquement définie sans vérification explicite. Des complexités supplémentaires surgissent avec les dépôts nus où "git status" et "git checkout" sont inopérants. Ces incohérences mettent en évidence les limites de la définition rigide de "branche actuelle" et soulignent l'importance de la compréhension contextuelle. La définition de "branche actuelle" comme cible pour les nouveaux commits, bien qu'elle soit généralement vraie, faiblit pendant un rebase où le commit atterrit finalement sur la branche d'origine. L'idée de "branche actuelle" représentant le contexte pour les opérations Git a du mérite, mais des disparités existent, comme "git status" se comportant différemment dans les dépôts nus. En fin de compte, la compréhension des nuances de "branche actuelle" nécessite de reconnaître sa nature dépendante du contexte et de se fier à une combinaison d'indicateurs tels que .git/HEAD, la sortie de "git status" et la dernière action de vérification pour une compréhension exhaustive.

L'auteur de l'article a organisé un sondage sur Mastodon pour demander aux gens combien ils étaient confiants dans leur compréhension de la manière dont HEAD fonctionne dans Git, et les résultats ont montré que beaucoup de gens étaient incertains ou n'avaient aucune idée. L'auteur pensait initialement que HEAD était un sujet simple, mais a découvert qu'il était plus compliqué qu'il ne l'appréciait après avoir eu des conversations suivantes avec d'autres. HEAD peut faire référence à différentes choses, y compris le fichier .git/HEAD, le "paramètre de révision" HEAD dans les commandes comme git show HEAD, et les diverses manières dont HEAD est utilisé dans la sortie de Git. Le fichier .git/HEAD contient soit le nom d'une branche, soit un ID de commit, et détermine la branche actuelle dans Git. Si .git/HEAD contient un ID de commit, Git appelle cela "état de tête détaché", ce qui signifie qu'il n'y a pas de branche actuelle. Dans l'état de tête détaché, les nouveaux commits ne seront pas attachés à aucune branche et pourraient être difficiles à trouver ou même supprimés par la collecte des ordures de Git. L'auteur explique comment interpréter la sortie de diverses commandes Git qui utilisent HEAD, y compris git status, git log et les conflits de fusion. Ils suggèrent également que la terminologie de Git autour de HEAD pourrait être plus cohérente et intuitive.

- Gestion des tirages : `pull.ff only` ou `pull.rebase true` pour éviter de créer des commits de fusion lorsque la branche en amont diverge. - Lisibilité des conflits de fusion : `merge.conflictstyle zdiff3` améliore la visibilité des conflits de fusion en affichant le code original au milieu. - Modification de commit automatisée : `rebase.autosquash true` combine les commits `fixup!` avec leurs cibles pendant le rebase. - Empilage automatique : `rebase.autostash true` exécute `git stash` avant et après le rebase. - Automatisation de la poussée : `push.default current` ou `push.default simple` pousse la branche actuelle vers une branche distante correspondante ; `push.autoSetupRemote true` configure le suivi pour la première poussée. - Branche par défaut : `init.defaultBranch main` crée une branche `main` au lieu de `master` dans les nouveaux dépôts. - Amélioration des messages de commit : `commit.verbose true` affiche la différence de commit dans l'éditeur de message de commit. - Automatisation de la résolution des conflits : `rerere.enabled true` se souvient et automatise les résolutions de conflits de fusion. - Autocorrection : `help.autocorrect 10` permet à Git d'exécuter des autocorrections après un délai spécifié. - Visualisation des différences : `core.pager delta` utilise un visualisateur de différences avec mise en évidence syntaxique ; `diff.algorithm histogram` améliore la visibilité de la réorganisation des fonctions. - Fichier gitignore global : `core.excludesfile` spécifie un fichier gitignore global. - Configurations Git séparées : `includeIf` permet des configurations différentes pour les dépôts personnels et professionnels. - Prévention de la corruption des données : `transfer.fsckobjects` et les paramètres associés détectent et préviennent la corruption des données. - Autres options notables : Ignorer les blames, tri des branches, paramètres de couleur, sélection de l'éditeur, nettoyage des commits, paramètres de base, outils de différence, paramètres de fusion, pousser les tags suivants, sécurité du rebase, format de date des logs.

Les branches divergentes se produisent lorsque une branche locale et son homologue distant ont des historiques différents. Reconnaître la divergence est crucial, et les moyens de le faire incluent `git status`, `git push` ou `git pull`. La résolution de la divergence dépend de la situation. Une approche consiste à conserver les deux ensembles de modifications en utilisant `git pull --rebase`. Pour ignorer les modifications distantes, utilisez `git push --force`, mais utilisez `git push --force-with-lease` pour une sécurité accrue. Alternativement, pour écraser les modifications locales, utilisez `git reset --hard origin/main`. Ces solutions offrent des options pour résoudre la divergence en fonction du flux de travail et de la situation.

Le répertoire .git contient des informations essentielles pour le contrôle de version avec Git. HEAD pointe vers la branche actuelle. Les branches, les commits, les arbres et les blobs forment le cœur de Git, stockant l'historique des commits, les listes de fichiers et le code réel, respectivement. Les reflogs suivent les changements apportés aux branches, aux étiquettes et à HEAD. Les branches de suivi distant conservent les derniers commits des branches distantes, tandis que les étiquettes marquent des commits spécifiques. Le stash stocke les changements non commités. .git/config contient les paramètres du dépôt. Les hooks peuvent être utilisés pour automatiser les actions avant les commits. La zone de staging (index) prépare les fichiers pour les commits. Cette vue d'ensemble fournit une compréhension générale du répertoire .git, mais elle ne couvre pas toutes ses complexités.

Comprendre les commits Git est complexe, et les gens ont des modèles mentaux variés. Un sondage a révélé que 51% pensent aux commits comme des diffs (changements entre les versions), 42% comme des snapshots (état actuel des fichiers) et seulement 4% comme une histoire des commits précédents. Intérieurement, Git stocke les commits comme des snapshots, ce qui facilite les temps de checkout plus rapides. Cependant, il emploie également des packfiles pour compresser les données, stockant les fichiers comme des deltas (différences) pour économiser de l'espace. Malgré cette mise en œuvre basée sur les snapshots, les diffs Git sont calculés en reconstruisant les snapshots à partir des deltas et en les comparant. Un modèle mental "erroné" courant est de considérer les commits comme des diffs par rapport au commit précédent, ce qui, bien qu'inexact, peut encore être utile dans l'utilisation quotidienne. Le modèle mental le plus courant, qui considère les commits comme des diffs, s'aligne avec le focus typique sur les changements de code. D'autres modèles, tels que les snapshots, sont utiles pour comprendre les déplacements de fichiers et les commits de fusion. En outre, les gens peuvent associer les commits à des informations supplémentaires (par exemple, des e-mails, des conversations) ou les voir comme des états "avant" et "après".

Motivé par les problèmes avec les modifications ad-hoc lors de l'utilisation d'Ansible, l'auteur a choisi d'installer NixOS sur un serveur, ce qui offrait un contrôle plus précis sur les paquets et les utilisateurs. Le processus d'installation de NixOS a impliqué l'utilisation de nixos-infect, la copie de la configuration générée, la création d'un flake et le déploiement des modifications à l'aide de nixos-rebuild. Pour exécuter un service Go sur le serveur, l'auteur a défini la configuration du service dans un seul fichier .nix, permettant la création dynamique d'utilisateurs et le stockage persistant. Malgré la complexité de la syntaxe du langage Nix, l'auteur a apprécié la fiabilité et la gestion centralisée de la configuration offerte par NixOS. Cependant, des questions subsistent quant aux vérifications spécifiques effectuées pendant nixos-rebuild et à un workflow simplifié pour déployer les mises à jour de service. Dans l'ensemble, l'auteur considère NixOS comme prometteur, malgré les défis rencontrés dans le débogage et l'apprentissage de la syntaxe du langage.

Cette année, l'auteur a travaillé sur la publication d'un zine expliquant comment les entiers et les flottants sont représentés en mémoire. Ils ont également créé un outil pour visualiser comment les variables sont représentées en mémoire, appelé "memory spy". De plus, l'auteur a lancé un terrain de jeu pour expérimenter la représentation des entiers appelé "integer.exposed". Dans un projet plus large, l'auteur a cherché à montrer comment mettre en œuvre une pile de réseaux en utilisant Python. La première partie de ce projet, "Mettre en œuvre DNS en un week-end", a été publiée, suscitant de nombreuses implémentations dans diverses langues. L'auteur a donné une conférence principale sur la manière de rendre les concepts difficiles accessibles. Ils ont également publié plusieurs billets de blog et développé des prototypes liés à Git, y compris "git-commit-folders" et "git-oops". L'auteur a embauché un gestionnaire des opérations pour gérer la logistique de son entreprise, ce qui leur a permis de se concentrer sur l'écriture et la programmation. Ils ont migré vers Mastodon et ont trouvé cette plateforme plus propice aux discussions techniques. L'auteur réfléchit aux défis de la finalisation des projets, reconnaissant qu'ils prennent souvent plus de temps qu'attendu. Ils expriment leur gratitude pour le soutien qui leur permet de poursuivre leur travail unique.

- Le projet, "git-commit-folders", propose une nouvelle approche pour visualiser les commits Git en les montant comme des dossiers. - FUSE, NFS et WebDAV sont les systèmes de fichiers pris en charge, avec NFS comme principal focus en raison du manque de support des liens symboliques pour WebDAV. - Pour garder les implémentations synchronisées, une interface FS centrale a été créée, avec des adaptateurs pour NFS et WebDav. - Le grand nombre de commits dans le répertoire est géré en organisant les commits dans des dossiers par préfixe et en mettant en cache les hachages de commits empaquetés. - Le débogage a impliqué l'analyse des paquets NFS avec Wireshark et la gestion d'erreurs comme "non un répertoire" et "handle de fichier obsolète". - Les numéros d'inode ont été générés en hachant les chemins de fichiers pour éviter les boucles. - Le répertoire "branch_histories" affiche actuellement uniquement les 100 derniers commits pour chaque branche. - Les sous-modules sont actuellement ignorés. - Le support de NFSv4 est disponible, mais les avantages par rapport à NFSv3 ne sont pas clairs. - Le projet vise à rendre la structure interne de Git plus intuitive en représentant les commits comme des dossiers.

De nombreuses personnes perçoivent intuitivement une branche Git comme une ramification avec une branche parente. Cependant, Git définit internement une branche comme l'ensemble de l'historique de tous les commits précédents, et non juste les commits "ramifiés". Cela signifie que chaque branche contient le même historique complet. Internement, les branches sont stockées comme des fichiers de texte avec l'ID du commit le plus récent. Alors que Git manque de concept de relations entre les branches, le modèle intuitif s'aligne sur la manière dont les rebases, les merges et les demandes de tirage GitHub fonctionnent. Cependant, le manque de hiérarchie entre les branches et l'interface utilisateur non conventionnelle de Git pour isoler les commits ramifiés peuvent être confusants. La branche par défaut de GitHub a des privilèges spéciaux, mettant en évidence le concept de "branche spéciale" malgré la neutralité hiérarchique de Git.

L'auteur, initialement sceptique quant aux flocons Nix, a entrepris un voyage pour comprendre leur utilité, en tirant des parallèles avec les conteneurs Docker pour clarifier le concept. Alors qu'il reconnaissait la supériorité des flocons en matière de reproductibilité et de gestion des dépendances, l'auteur a cherché à les utiliser pour maintenir une liste centralisée des paquets système, recherchant des avantages dans la configuration du système et la désinstallation des logiciels. Au cours d'un processus d'essai et d'erreur, l'auteur a navigué les défis tels que les fichiers non suivis dans les dépôts Git, l'intégration de paquets non libres et la résolution des problèmes de chemins relatifs avec les dépendances des flocons. En utilisant 'nix develop' et 'buildEnv', l'auteur a réussi à créer un répertoire de liens symboliques représentant les paquets souhaités. Cependant, le processus n'a pas été sans obstacles, rencontrant une erreur liée aux hooks de construction qui a entravé le progrès. Malgré les difficultés, l'auteur est resté persévérant dans son exploration des flocons, cherchant une approche plus fluide et plus gérable pour son flux de travail de gestion des paquets Nix. L'auteur a trouvé les explications existantes des flocons difficiles à saisir, s'appuyant plutôt sur des analogies et des expériences pratiques pour développer sa compréhension. Bien que la première incursion de l'auteur dans les flocons ait présenté des défis, son engagement à maîtriser cet aspect de Nix met en évidence un désir d'expérience de gestion de paquets plus solide et plus efficace.

L'auteur, initialement méconnaissant git cherry-pick comme simple application d'un patch, explore réellement son fonctionnement, révélant un processus plus nuancé impliquant un "merge à trois volets". La méconception est apparue lors de la tentative de résolution des conflits de fusion en utilisant la méthode de patch, qui a échoué, contrairement au comportement attendu de git cherry-pick. Des recherches supplémentaires dans le code source de git ont révélé que cherry-pick utilise un merge à trois volets, un concept inconnu de l'auteur à l'époque. Cela a incité à explorer les merges à trois volets, qui, en substance, consistent à fusionner deux fichiers en les comparant à leur version originale (la base). Ce concept s'étend à l'application des patches dans git, où les versions du fichier avant et après le commit, ainsi que le fichier actuel, constituent les trois versions utilisées dans le merge. Cherry-pick, rebase et revert utilisent tous cette stratégie de merge à trois volets, se distinguant principalement par l'ordre et l'interprétation des versions de base et cible. L'auteur forge le terme "patch à trois volets" pour décrire cette technique, mettant en avant son avantage de fournir plus de contexte pour la fusion par rapport aux patches traditionnels. Alors que git apply gère généralement les patches traditionnels, il offre également un drapeau --3way pour effectuer des merges à trois volets. Cette exploration met en évidence l'intelligence de l'utilisation des merges à trois volets pour appliquer des patches dans git, offrant une approche unifiée pour diverses opérations tout en restant transparent pour les utilisateurs qui peuvent se contenter du concept familier d'"application d'un patch". L'auteur reconnaît la complexité de la fusion dans git, évoquant des concepts tels que les merges récursifs et les algorithmes de fusion multiples, avec le livre "Building Git" suggéré pour une exploration plus approfondie. Enfin, l'auteur exprime son admiration pour la conception élégante du mécanisme de patching de git, louant son intuitivité et son efficacité.