Question 1

How is this different from git add -p?

Accepted Answer

git add -p is interactive staging where you split or edit hunks by hand. This classifies hunks from a sentence you write and never splits or edits a hunk — the whole hunk goes in or stays out. It also never commits. If you already know which lines you want, a tool that takes explicit hunk ids and line ranges is a better fit; if you want the working tree grouped into whole commits, that is a different tool again.

Question 2

What happens if my working tree changes while it is building the plan?

Accepted Answer

Nothing is staged and the command exits 3. It hashes HEAD, the index bytes and the full diff before the plan, then re-checks all three while holding index.lock before renaming the new index into place, so a concurrent change cannot be half-applied. Exit 3 also covers a locked index. Just run it again.

Question 3

Can it stage part of a hunk, or a file I just created?

Accepted Answer

Not part of a hunk — a hunk is staged whole or not at all, and mixed is how it reports wanted and unwanted lines in the same block. Untracked files are not classified at all; run git add -N on a new text file first. Empty new files and mode-only changes cannot be staged by hunk and are listed as skipped, so those need a plain git add.

Question 4

What does it send to TypeSafe and what does it write to my repo?

Accepted Answer

The staging sentence, any --exclude sentence, changed file paths, hunk headers and hunk text are sent to api.typesafe.ai. Locally it writes a temporary private index and updates the repository index, and it does not write working-tree files. It needs Git 2.30 or newer, Node 22 or newer, and a TypeSafe key, which it reads from the environment or the nearest .env between the current directory and the repository root.

Question 5

What are the exit codes and what do the flags do?

Accepted Answer

Exit 0 means done or nothing to stage, 1 an error, 2 a usage problem, and 3 that the snapshot went stale or the index is locked, which means rerun it. Flags include --exclude for a sentence describing out-of-scope changes, --dry-run to print the plan and patch with no prompts and no changes, --yes to skip confirmation while leaving mixed hunks unstaged and listed, --json for one document on stdout with the plan on stderr, and --threshold to set the confidence needed to take include or exclude as given, default 0.6.

Question 6

Can I use it as a library or from a coding agent?

Accepted Answer

Both. planSelection reads the unstaged diff and returns a Plan without reading TYPESAFE_API_KEY or touching the index, and applySelection applies your chosen hunk ids, preserving existing staged changes and returning stagedHunkIds, skippedMixedIds and patchBytes. For agents, --json lists every hunk with its id, header, text, decision and source, plus confidence and probabilities, and a FakeProvider lets tests script answers through the same validator.

Question 7

How is the actual classification request built?

Accepted Answer

One choice question per hunk with three options: include when every changed line belongs to your sentence, exclude when none does, and mixed when some do. The sentence and any neighbouring hunks from the same file that fit travel along as context, and oversized diffs are split into windows and sent concurrently. Hunks are cut with 6 lines of context using fixed git diff flags, and anything too large to fit is reported with source too-large rather than guessed at.

Git Jev Stage

About this project

Highlights

Questions about this entry

More Jev resources like this

From the Jev community