build-git / lesson-36.md
Lesson 36 · Status and the capstone

status: unchanged versus modified

The core of status compares each staged file's current content against what the index recorded. Equal ids mean unchanged; different ids mean modified. Today you classify a tracked file.

The goal

Classify a tracked file as unchanged or modified by comparing its working id to its index id.

Start here - the target
TO DO
Scenario: A tracked file is unchanged or modified
Givenan index recording hello.txt at ce013625030ba8dba906f756967f9e9ca394464a and a working hello.txt
WhenstatusOf(hello.txt) compares WorkingId(hello.txt) to the indexed id
Thenif the file still contains hello and a newline the ids match and it is unchanged
Andif the file now contains hello world and a newline its working id is 3b18e512dba79e4c8300dd08aeb37f8e728b8dad, which differs from the indexed id, so it is modified
Background

For any path that is both on disk and in the index, the question is simple: does its current content still match what was staged? Compute the working id and compare it to the index id. Same id, unchanged; different id, modified. There is no special content comparison because content equality is id equality.

This is the everyday heart of git status: it tells you which tracked files you have edited since staging them. Right after add, a file is unchanged; edit it and it becomes modified until you stage it again (which updates the index id to match). Two more cases complete the picture, a file that is in the working tree but not the index, and one in the index but no longer on disk, which are next.

Make it work
// compare the file's current id to what the index recorded
wid, _ := r.WorkingId(path)
if wid == ix.entries[path].Id {
return "unchanged"
}
return "modified"
CheckpointDONE
You can tell a modified file from an unchanged one. Commit and stop here.