Sidequest: Hunks, or Why Diffs Come in Lumps

Cold open

A hunk is one patch of change inside a diff: a run of lines that were removed, added or both, together with a few unchanged lines on each side so you can tell where it goes.

Where it showed up

You were finishing a prompt audit of the pargrafik CLAUDE.md. The audit had proposed a set of edits: pin notes before pixel coordinates, the word "now" removed from two lines, the studio story moved to the log, and four warning markers turned back into plain text. These came as five separate pieces of change. When Claude said "I applied all five hunks", it meant it had applied every one of those pieces, with none skipped. Then it ran a diff of the file and went through each removed line, which is the "verify by diff, not by intent" rule doing its job.

You did not ask what a hunk is. You asked why the word is hunk and not chunk, block, piece or anything else. That is about vocabulary, so it gets a short answer.

Why a hunk is its own thing

Start with what a diff does. Comparing two versions of a file, the diff tool finds the lines both versions share and then reports what is left over: the places where they differ. Those differences come in clumps. A file of 300 lines with five edits does not give you one long change. It gives you five islands of change in a sea of untouched text.

Each island needs a name, and it needs to work as a unit, because the tool on the other end, the one that applies the change, handles it as one. Every island carries 3 things. First, a header saying roughly where it sits, something like "around line 40 in the old file, around line 41 in the new one". Second, the lines that went out and the lines that came in. Third, by default 3 unchanged lines on either side as context.

That context is the clever part. It lets the applying tool find the right spot even if the file has moved a bit since. Say someone added 10 lines at the top in the meantime. The line numbers are now wrong, but the context still matches, so the tool searches nearby, finds those 3 familiar lines and puts the change there. That is why the old patch program reports things like "Hunk number 2 succeeded at line 52, offset 10 lines". It is saying the hunk landed, just not where the address said.

There is also a quirk you may have noticed without knowing why. Two edits that sit close together, within about 6 lines of each other, merge into one hunk, because their context lines overlap. So "five hunks" means five clumps of change as the tool happened to group them, not exactly five edits as a human would count them. Two tweaks in neighbouring sentences come out as one hunk.

So why "hunk"?

Here is the honest version. I could not find a confirmed record of who first said "hunk" for this. What is solid is the lineage. Larry Wall, who later created Perl, wrote the patch program in 1985, and its messages counted hunks one by one. GNU's version of patch is a fork of Wall's, and the GNU diff tools use the same word. Git inherited the whole vocabulary: its glossary defines a hunk as one run of consecutive lines with context inside a larger patch. When you stage part of a file interactively, git literally asks "Stage this hunk?" So the word was in the tools by the mid-80s, and everything since has copied the tools.

Why that word in the first place? My guess, and it is only a guess: in plain English a hunk is a rough, irregular piece torn off something bigger, like a hunk of bread or a hunk of cheese. That fits exactly. A hunk has no fixed size and lands wherever the edits happened to be.

Compare the candidates. "Chunk" means nearly the same thing, but in computing it was already taken by fixed-size pieces of data, such as chunked uploads, memory chunks and file formats built from chunks. "Block" is worse, since it means something rigid in disks and in code. "Section" and "region" suggest the file's own structure, but a hunk ignores structure entirely: it can start halfway through a paragraph and end in the middle of a table. "Hunk" had no competing meaning and the right feel of a rough piece. Programmers took it and it stayed.

It also has a useful side effect. Because the word is a bit odd, it is unambiguous. Say "I applied five chunks" and someone will ask chunks of what. Say "I applied five hunks" and anyone who has used diff knows you mean five contiguous runs of change, each with its context, each applied or rejected on its own.

Where it lives in your estate

You meet hunks everywhere, mostly without the name. Every review gate in slash cowork, where Codex looks at a change, is reading hunks. The ⛔ rule in your global instructions, "verify by diff, not by intent", is a rule about reading every hunk before committing, especially its minus lines, because that is where a feature quietly disappears. And when a session stages only some of a messy working tree, which your git rules push for when they say to stage by filename and never add everything, the finer version of that is picking individual hunks.

If you remember one thing:

A hunk is one rough lump of change plus a few lines of context so it can find its way home, and the name stuck because "chunk" was already taken and a lump is exactly what it is.