A coding agent finishes a task and leaves one large set of changes in your working tree: the feature you asked for, a refactor it did along the way, some formatting, and a config tweak. Committing it all at once is quick, but it makes the history harder to review, harder to revert, and harder to understand later.

This guide shows how to split an agent run into focused commits with standard Git commands, and how to decide what goes together.

Decide the groups before you stage anything

Read the full diff first and sort changes into groups. A typical agent run might contain:

  1. The requested change and the tests for it.
  2. Supporting changes that the request depends on, such as a new type or a helper.
  3. Incidental refactors the agent made while it was there.
  4. Formatting-only changes.
  5. Unrelated edits, such as configuration, dependencies, or a fix in another module.

Groups 1 and 2 usually belong together. Groups 3 to 5 are candidates for their own commits, or for removal. A good test for a group: could you revert it on its own without breaking the others? If not, it belongs with the change it depends on.

Start with an overview:

git status --short
git diff --stat

Stage by hunk with git add -p

git add -p walks through each hunk and asks whether to stage it. The most useful answers are:

  • y to stage the hunk and n to skip it
  • s to split the current hunk into smaller hunks
  • e to edit the hunk by hand, for when two unrelated changes sit on adjacent lines
  • / to search for a hunk matching a regular expression

A workflow for the first commit:

git add -p            # stage only the requested change and its tests
git diff --cached     # review exactly what will be committed
git commit

Then repeat for each remaining group. git diff --cached shows what is staged and git diff shows what is left, so you can always see both halves.

New files are not shown by git add -p until Git knows about them. git add -N <file> records that a file will be added, so its contents appear as hunks you can stage.

Check that each commit works on its own

Splitting a change can create a commit that doesn't build: the feature commit might use a helper that you put in a later commit. After committing, check each commit, or at least the first one, by running your build and tests at that point in history.

If a commit is missing something, you can fix it with an interactive rebase or by resetting and staging again. It is easier to catch this before you push.

Remove what you don't want

Some groups should not be committed at all. For hunks you want to throw away, git restore -p <file> discards changes in the working tree hunk by hunk. It is permanent for uncommitted work, so review each hunk before confirming.

If an unrelated change looks useful, you can keep it on a separate branch instead. One way is to commit it on its own and move that commit later, another is to use git stash push -p to set it aside for now.

Keep the agent's request in the history

Write commit messages that say why, not just what. For the main commit, restating the request helps whoever reads the history next, including you. For separated commits, say why they were split out: "Formatting only, from the same agent session" or "Unrelated config change, kept separately for review".

Where Diffward fits

Diffward is a VS Code extension that groups a local agent session into one review. It helps with the sorting step: it shows files that look unrelated to your request first, then high-risk changes, and folds formatting-only hunks away. You can ward (keep) or discard each hunk and undo either decision.

Warding a hunk is a review decision, not a Git operation. It does not stage or commit anything, so you still use git add -p or your editor's staging tools to build the commits.

A short checklist

  • Have you read the whole diff and sorted it into groups?
  • Does each group revert cleanly without breaking the others?
  • Did git diff --cached show exactly what you meant before each commit?
  • Does each commit build and pass tests on its own?
  • Did you remove or set aside what doesn't belong?

Conclusion

An agent can produce a lot of change in one run, but that doesn't mean it all belongs in one commit. A few minutes with git add -p turns a mixed diff into commits that each have one reason to exist, which pays off the next time someone needs to review, bisect, or revert them.