<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>git on Maëlle Salmon&#39;s personal website</title>
    <link>https://masalmon.eu/tags/git/</link>
    <description>Recent content in git on Maëlle Salmon&#39;s personal website</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <copyright>Licence: &lt;a href=&#34;https://creativecommons.org/licenses/by-sa/2.0/&#34;&gt;CC BY-SA&lt;/a&gt;</copyright>
    <lastBuildDate>Tue, 19 May 2026 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://masalmon.eu/tags/git/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>More crochet/programming thoughts</title>
      <link>https://masalmon.eu/2026/05/19/crochet-again/</link>
      <pubDate>Tue, 19 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://masalmon.eu/2026/05/19/crochet-again/</guid>
      <description>Here I am again, writing about crochet and programming! I’ve continued creating my tons of shitty stitches cute creatures.
New Git analogy! The crochet lifeline First Git/crochet analogy.
I read a great crochet book about creating your own amigurumi patterns: Créer ses propres modèles d&amp;rsquo;amigurumis au crochet by Clotilde Massot and Lise Grandjonc. One of its authors (Clotilde Massot) is a software developer who, among other things, published an octocat pattern that I bought and used… Anyway in the book they explain that when you create a pattern, you will probably have to undo your work several times.</description>
    </item>
    
    <item>
      <title>Git worktrees are now cool</title>
      <link>https://masalmon.eu/2026/04/23/git-worktree-again/</link>
      <pubDate>Thu, 23 Apr 2026 00:00:00 +0000</pubDate>
      
      <guid>https://masalmon.eu/2026/04/23/git-worktree-again/</guid>
      <description>I&amp;rsquo;m not mad when current AI tools or tips1 make Git look cool and important. Something old and stable to cling to! 🤗 In particular, it&amp;rsquo;s now trendy to have agents work on different tickets in the same project in parallel by using Git worktrees. Git worktrees are even useful for us humans, even if we should probably not work on a dozen things at the same time.
I had learnt about Git worktrees a while ago, but only viewed them as a way to open a read-only view of a past version of a repository: I have written about loading different R package versions at once with git worktree.</description>
    </item>
    
    <item>
      <title>Better Git diff with difftastic</title>
      <link>https://masalmon.eu/2026/03/30/difftastic/</link>
      <pubDate>Mon, 30 Mar 2026 00:00:00 +0000</pubDate>
      
      <guid>https://masalmon.eu/2026/03/30/difftastic/</guid>
      <description>I&amp;rsquo;m currently on a quest to better know and understand treesitter-based tooling for R. To make it short, treesitter is a tool for parsing code, for instance recognizing what is a function, an argument, a logical in a string of code. With tools built upon treesitter you can search, reformat, lint and fix, etc. your code. Exciting stuff, running locally and deterministically on your machine.
Speaking of &amp;ldquo;etc.&amp;rdquo;, Etienne Bacher helpfully suggested I also look at treesitter-based tooling for other languages to see what&amp;rsquo;s still missing in our ecosystem.</description>
    </item>
    
    <item>
      <title>Zut, Git ! Porting {saperlipopette} to the terminal with Claude</title>
      <link>https://masalmon.eu/2026/02/27/zut-saperlipopette-claude/</link>
      <pubDate>Fri, 27 Feb 2026 00:00:00 +0000</pubDate>
      
      <guid>https://masalmon.eu/2026/02/27/zut-saperlipopette-claude/</guid>
      <description>A while ago, I decided to learn some Rust. I bought a book, opened it months later and started a small side-project: porting my R package saperlipopette to the terminal by writing a CLI with Rust. I then lost steam and discarded the project. Now, teaching more Git with saperlipopette has me itching to do the same outside of R, to reach more learners. And in the meantime, even though I have conflicting feelings about it, I realized that using an LLM, specifically Claude Code (Opus 4.</description>
    </item>
    
    <item>
      <title>Git commits: please mark your stitches!</title>
      <link>https://masalmon.eu/2026/02/15/stitch-markers-git-commits/</link>
      <pubDate>Sun, 15 Feb 2026 00:00:00 +0000</pubDate>
      
      <guid>https://masalmon.eu/2026/02/15/stitch-markers-git-commits/</guid>
      <description>In which I share a crochet analogy for Git commits…
This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas.
Don’t forget your stitch markers! I am happily continuing my crochet learning journey. One lesson I have now internalised is that I should never ever forget or neglect to use stitch markers. Stitch markers are sort of small, not spiky, safety pins.
  A crochet project featuring several stitch markers (beginning of a Snorlax from Lee Sartori&amp;rsquo;s Pokemon crochet book)</description>
    </item>
    
    <item>
      <title>Does my test really validate a bug fix? Check it with git cherry-pick</title>
      <link>https://masalmon.eu/2024/08/29/cherrypick-test/</link>
      <pubDate>Thu, 29 Aug 2024 00:00:00 +0000</pubDate>
      
      <guid>https://masalmon.eu/2024/08/29/cherrypick-test/</guid>
      <description>Earlier this year I wrote a post about git worktree that allows you to load different versions of an R package at once on your computer. To keep with the &amp;ldquo;juggle between versions of a codebase with Git plant-related commands&amp;rdquo; theme, let me show you how I use cherry-pick to assess the quality of an unit test.
Scenario: you fix a bug in a branch In a perfect world, the bug you&amp;rsquo;re working on is paired with a ✨ reprex ✨, and you even start your work by adding a test case for it.</description>
    </item>
    
    <item>
      <title>Hack your way to a good Git history</title>
      <link>https://masalmon.eu/2024/06/11/rewrite-git-history/</link>
      <pubDate>Tue, 11 Jun 2024 00:00:00 +0000</pubDate>
      
      <guid>https://masalmon.eu/2024/06/11/rewrite-git-history/</guid>
      <description>I&amp;rsquo;ve now explained on this blog why it&amp;rsquo;s important to have small, informative Git commits1 and how I&amp;rsquo;ve realized that polishing history can happen in a second phase of work in a branch. However, I&amp;rsquo;ve more or less glossed over how to craft the history in a branch once you&amp;rsquo;re done with the work.
I&amp;rsquo;ve entitled this post &amp;ldquo;Hack your way to a good Git history&amp;rdquo; because writing the history after the fact can feel like cheating, but it&amp;rsquo;s not!</description>
    </item>
    
    <item>
      <title>Why you need small, informative Git commits</title>
      <link>https://masalmon.eu/2024/06/03/small-commits/</link>
      <pubDate>Mon, 03 Jun 2024 00:00:00 +0000</pubDate>
      
      <guid>https://masalmon.eu/2024/06/03/small-commits/</guid>
      <description>This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas.
&amp;ldquo;Make small Git commits with informative messages&amp;rdquo; is a piece of advice we hear a lot when learning Git. That&amp;rsquo;s why we might want to sometimes rewrite history in a branch. In this post, I&amp;rsquo;d like to underline three main (😉) reasons why you&amp;rsquo;ll be happy you, or someone else, made small and informative Git commits in a codebase.</description>
    </item>
    
    <item>
      <title>Load different R package versions at once with git worktree</title>
      <link>https://masalmon.eu/2024/01/23/git-worktree/</link>
      <pubDate>Tue, 23 Jan 2024 00:00:00 +0000</pubDate>
      
      <guid>https://masalmon.eu/2024/01/23/git-worktree/</guid>
      <description>This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas.
Do you ever see GitHub issue comments where someone posts the results of a reprex with a current package version, and then with an older one, to prove a regression? How would you go about preparing such a report? Today I learnt there is a clean way to have different versions of a codebase at once on your computer, thanks to the ever powerful Git.</description>
    </item>
    
    <item>
      <title>Reading notes on Pro Git by Scott Chacon</title>
      <link>https://masalmon.eu/2024/01/19/pro-git-scott-chacon-reading-notes/</link>
      <pubDate>Fri, 19 Jan 2024 00:00:00 +0000</pubDate>
      
      <guid>https://masalmon.eu/2024/01/19/pro-git-scott-chacon-reading-notes/</guid>
      <description>As mentioned about a million times on this blog, last year I read Git in practice by Mike McQuaid and it changed my life &amp;ndash; not only giving me bragging rights about the reading itself. 😅 I decided to give Pro Git by Scott Chacon a go too. It is listed in the resources section of the excellent &amp;ldquo;Happy Git with R&amp;rdquo; by Jenny Bryan, Jim Hester and others. For unclear reasons I bought the first edition instead of the second one.</description>
    </item>
    
  </channel>
</rss>