A gentle introduction to quilt
Or, patch management for software.
Speaker Intro
Hi, I'm bjb. I'm a programmer.
Motivation and topic intro
I needed to learn how to use the software tool "quilt", so you get to listen to my podcast about an introduction to quilt.
People collaborating on a project must edit the same set of source files. After one person commits some changes, then the other people must rebase their own changes on the new version of the shared files before they can push their changes.
A minor fix for some old typo should not be in the same patch as a new feature; a comment correction should also be in its own patch. Essentially, two new features and some bug fixes should not all be smushed together in one patch. Each feature should be in its own patch (or patch series), and each bug fix should be in its own patch. This allows others to be able to review the proposed changes easily, and even lets them pick and choose which patches they want to apply. It becomes a chore to manage all these patches. That's where quilt comes in.
Sadly, I hadn't learned quilt till this weekend ... well one way to ensure I learn it fairly well is to write a HPR episode about it! Here goes.
I have written this episode to be understandable by anyone - you don't have to be a coder. You could use this tool to keep track of any plain-text files - recipes, todo lists, html, hpr show notes, poetry, what-have-you.
Introduction
First let's describe what a patch is. No, first let's describe what source code looks like. Source code is a plain text file full of computer instructions. It is a plain text file, as opposed to a word processing file. Plain text files do not have any formatting codes or styles in them (such as which font should be used, or what colour, and so on). They just contain the characters that make up words of the content.
A key feature of these source code files is that a new section of the file starts on a new line. The source code is almost never "reflowed" like prose might be. It is sort of like poetry - the more formal poetry, not prose poetry. There are a lot of really small sections in source code files (called "statements" and "expressions"). Most of these sections fit on one line. This is useful for the tools we're going to discuss because when one line changes it does not affect the following lines, as it might when text is reflowed after a change.
People have been coding with plain text files in various languages for decades. Thus a large set of tooling has grown around this format. One of those tools is called "diff" and another one is called "patch".
Diff is a way to compare two text files. Typically it would be used to compare the "before" and "after" of a source code file undergoing changes. So you could find out what was done to the source code file by running diff on the before and after versions of that file.
A diff file is a series of excerpts from the original and changed files. There are various kinds of diffs. Some of them show only the changed lines. Some of them show a few lines before and a few lines after in addition to the changed lines themselves. That second kind is called a "context diff" and helps the automated machinery (and humans too) find the correct part of the file to which the change must be applied.
By default there are 3 lines of context before and after the changed lines.
The changed part is represented by including the old AND new line. In order to distinguish which lines are old and which are the replacements, all the lines (context lines, removed lines and added lines) are shifted over to the right by one character. The context lines start with a space
