You Cleaned the File. What Will Git Actually Commit?

Cleaning a file in your editor does not necessarily remove an earlier staged version. Conversely, reviewing the staging area does not freeze what a later git commit -a will include. Before letting a coding agent commit a change, review both the intended content and the command that will select it.

We reproduced these boundaries in temporary local Git repositories using invented markers, not real credentials. One ordinary commit recorded a dummy value that had already been removed from the working file. A separate -a commit included a tracked edit made after the staged version was reviewed. These were actual Git commits, not an importer model or a simulation of a hosting service.

Three copies, three different questions

For the ordinary files in this experiment, it helps to separate:

The Git diff reference distinguishes these comparisons: plain git diff compares the working tree with the index; git diff --cached compares staged content with HEAD by default. An empty plain diff can mean that the working file exactly matches the staging area, even when both contain something you did not intend to commit.

The Git add reference explains that adding a file records its content at that time. Editing it afterward is a separate change. A clean-looking editor tab is therefore not evidence about the previously staged bytes.

Our Gitignore boundary experiment covers whether paths are tracked or ignored and what remains in old history. This article addresses a narrower next-commit question: which version is selected when the commit command finally runs?

Seven outcomes from real, disposable repositories

We ran the fixture with Git 2.50.1 (Apple Git-155) and Python 3.14.3 on macOS. It creates four temporary repositories, supplies dummy author information only to its child processes, and uses no remote or network. The marker DEMO_ONLY_NOT_A_CREDENTIAL is invented.

The Git commit reference documents different selection rules for ordinary commits, -a, and explicit paths. None of these modes is inherently wrong. The mistake is reviewing one selection and assuming a different command will preserve it.

This fixture does not test hooks, external content filters, merge conflicts, partial-staging interfaces, IDE commit behavior, or an agent running concurrently. Those can require additional checks. It is not a credential scanner, and it does not prove that a reviewed snapshot contains no secrets.

Run the fixture without touching a project

Download the standalone synthetic lab, read it, and run it with an existing Python 3 installation:

python3 git-commit-snapshot-lab.py

The tested environment uses /usr/bin/git. The script is not a Windows walkthrough, and other Git versions have not been exercised here. It takes no repository or credential arguments and does not inspect your current repository. All commits and file changes happen under its own temporary directory, which is removed when the test exits.

The fixture isolates Git configuration and uses an empty hooks directory inside its temporary test environment so user-installed hooks are not run. That is a test-control choice, not advice to disable checks in a real repository. It prints seven boolean outcomes and version information, not production file contents.

Review the selected snapshot, not just the editor

For your real task, first agree which paths may change and whether anyone else is modifying the repository. Do not apply the fixture’s staging or commit commands to a shared worktree merely to see what happens.

These read-oriented checks help locate the current differences:

git status --short
git diff --name-status
git diff --cached --name-status

They show paths and status, not whether the bytes are appropriate. Review the staged patch locally using your normal review tool or git diff --cached. A patch may display a real secret if one is present: do not paste it into a public support request or send it to an unapproved service. Our MCP log-sharing guide explains why sanitizing one remembered value does not clear an entire artifact for sharing.

In the synthetic lab, git show :config.txt reads the staged version and git show HEAD:config.txt reads the committed version. Those commands are useful for understanding the distinction, but displaying a real project’s file contents requires the same care as opening the file itself. A name-only check is not a substitute for reviewing content, and content review is not a reason to expose it elsewhere.

Before committing, record the exact intended mode. If the review covered the index, a later -a, explicit path list, automatic IDE staging, or additional git add can invalidate that review. If the file changes again, review the newly selected snapshot. Do not use git add . as a generic way to make a review mismatch disappear; it can include unrelated work.

If a specific correction is authorized, select that correction deliberately and review it again. Whole-file staging can also replace an intentional partial selection, so keep the existing staging plan in view. This article does not prescribe a reset, stash, history rewrite, or force push.

Give the agent an explicit completion condition

You can adapt this instruction after agreeing the task scope:

Before committing, identify the authorized paths and the commit mode.
Review the exact content selected by that mode.
If staging or working files change after review, re-review the selection.
Preserve unrelated staged and unstaged work.
After an authorized commit, inspect its paths and content before reporting success.
Do not print credentials or send full diffs to an unapproved destination.

A written rule is a reminder, not an access control. Our AGENTS.md and CODEOWNERS review-boundary guide separates instructions from review routing and merge enforcement. You can use the rules gallery as a starting point for project-specific instructions, but verify what your actual tools execute.

If a real credential was already committed or shared, fixing the next commit does not revoke it or erase earlier copies. Follow the relevant provider’s response process through an authorized operator. The lab uses only fake markers and performs no credential operation.

Where a paid secrets workflow does—and does not—help

The problem demonstrated here can be diagnosed with free Git commands. Buying a secrets manager does not change Git’s index semantics or make commit -a equivalent to the snapshot you reviewed.

If your separate requirement is distributing credentials to several people or jobs without routinely copying plaintext into project files, the existing secret-management buying discussion explains what to assess. No purchase is needed for this experiment, and this article adds no direct affiliate link.

The decision for this task is simpler: preserve the user’s changes, review the content the chosen command will record, and verify the resulting commit. That is a specific acceptance check you can use before introducing another product.