The missing half of git add.
git add -p is interactive. Your agents can't use it.
Zig · v0.10.1 · MIT
The problem
Partial staging is interactive-only
The only built-in way to stage individual hunks is git add -p — an interactive prompt that blocks automation.
Interactive staging
- ✗ Requires a human at the keyboard
- ✗ Blocks CI/CD pipelines
- ✗ Non-deterministic hunk ordering
- ✗ Unusable by LLM agents
Hash-based staging
- ✓ Fully non-interactive
- ✓ Stable SHA-1 content hashes
- ✓ Deterministic across runs
- ✓ Machine-readable output
How it works
Enumerate. Select. Stage.
Three commands. No prompts. No interaction.
1
Enumerate
See every hunk with a stable content hash. Same content always produces the same hash.
2
Select
Inspect any hunk by its hash prefix. Review the full diff before staging.
3
Stage
Stage by hash — deterministic and scriptable. Remaining hunk hashes stay stable.
The key insight
Hashes that don't break
When you stage a hunk, the remaining hashes stay the same. This is what makes scripted multi-step workflows reliable.
Before staging
After staging
How it works
SHA1( file_path + '\0' + stable_line + '\0' + diff_lines )
Hashes use the immutable side's line numbers. Staging one hunk can't shift another hunk's anchor point, so hashes remain stable across operations.
Built for
Stage hunks by hash, not by prompt
>_
LLM Agents
Agents can't drive interactive prompts. git-hunk gives them deterministic hashes to enumerate, select, and stage programmatically.
--porcelain
#!/
Scripts & CI
Deterministic staging in pipelines. Use count as a guard and check to validate hashes before staging.
--exclusive
$
Humans
No more y/n/q/a/d/e/? guessing. See all hunks at once, inspect any hunk by hash, stage exactly what you want.
--oneline
Commands
Everything you need
list
Enumerate hunks with stable content hashes
diff
Inspect a hunk's full diff before staging
count
Count available hunks — bare integer for scripting