# Self-Review Your Working Diff Before Committing in Java with Atlas (2026) > Atlas reads git status and the raw diff of your uncommitted Java change, greps for debug leftovers like @Disabled, and gates the commit on JUnit 5 via mvn test and Spotless. To self-review your working diff before committing in a Java project, have Atlas produce the diff with its bash tool and read it end to end, not just the classes you remember touching. Atlas reads git branches, status, and diffs, so the uncommitted change in your `src/main/java` tree is visible to the agent as a real unified diff. Atlas then reads each changed file in full to check the change against its surroundings, greps for debugging leftovers such as System.out.println calls or @Disabled annotations you added, and finally runs JUnit 5 via mvn test and Spotless through bash before you commit. ## Key takeaways - Atlas reads git branches, status, and diffs, so your uncommitted Java change is reviewable as a real unified diff. - Read each changed Java class in full, because a diff hides the equals, hashCode, and overrides it did not touch. - Grep the diff for System.out.println, printStackTrace, and JUnit 5 @Disabled before you commit. - Session revert restores from a git-patch snapshot and refuses to run on a busy session. - Gate the commit on JUnit 5 via mvn test for correctness and Spotless for formatting, in that order. ## How do I get Atlas to review my uncommitted Java diff? Atlas reads git branches, status, and diffs, so producing the working diff of a Maven project is one bash call away. Read the whole diff end to end, not just the 3 or 4 classes you remember touching, because a Java refactor across `src/main/java` almost always drags in a file you forgot. Start by having Atlas run the diff through bash and read every hunk, including the ones in `pom.xml` and any `build.gradle` you touched. Build-file changes are the easiest thing to miss in a Java review and among the most consequential: a dependency version bumped while chasing a compile error is a real change that belongs in the commit message. Atlas's VCS layer surfaces status and the raw diff, so untracked files show up too. A new `src/test/java/.../FooTest.java` that was never added to git is invisible to a reviewer and to CI, and status is where you catch it. ## Why read each changed Java file in full and not just the diff? A diff hides everything it did not touch. Atlas reads each changed Java file in full to check the change against its surroundings, because a 3-line edit to a method in `OrderService.java` can be correct in isolation and wrong against the class invariants, the constructor, and the other 12 methods the diff never showed you. Java makes this failure mode concrete. Adding a field to a class means the equals and hashCode implementations below the diff window are now stale. Changing a method signature means overloads elsewhere in the same class may now be ambiguous. Narrowing a return type means a subclass override no longer compiles. None of that is visible in a unified diff. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so reading the class gives it the real declaration boundaries and it can tell you which members of `OrderService` interact with the lines you changed. ## How do I find debugging leftovers in a Java diff before I commit? Atlas greps the working diff for the debugging leftovers you introduced: temporary logging, skipped tests, commented-out blocks. In Java the specific offenders are System.out.println calls, a printStackTrace added while chasing an exception, and a JUnit 5 @Disabled slapped on a test to make mvn test go green. The grep pass is short and catches the things reviewers most resent finding. Search the changed files for println, printStackTrace, @Disabled, @Ignore, and TODO markers you added in the last hour. Search for commented-out method bodies, which in Java tend to be whole blocks left behind after a refactor. A @Disabled annotation is especially dangerous because JUnit 5 via mvn test will report a green build while quietly not running the test that would have caught the bug. Atlas can grep the diff rather than the whole repository, which keeps the results scoped to what you are about to commit. ## How do I undo a change Atlas made without hand-reverting it? Atlas snapshots file changes as git patches, so an unwanted edit in your Java working tree can be diffed and rolled back in 2026 rather than hand-reverted. The session revert flow is backed by those snapshots, and it refuses to run on a busy session, which prevents a half-written turn from being rolled back mid-flight. Self-review often ends with a verdict of "that change was wrong". In a Java codebase, hand-reverting an edit that touched an interface, its two implementations, and the tests is tedious and error-prone. Atlas's session revert restores from a snapshot instead. The busy-session guard matters: if Atlas is mid-turn writing to `src/main/java`, revert refuses rather than restoring a partially written tree. After a revert, re-run the diff through bash and confirm the working tree is back where you expect before continuing. ## What should I run before committing a Java change? Run the tests and the linter with Atlas's bash tool, then commit. For a Maven project that means JUnit 5 via mvn test for correctness and Spotless for formatting, in that order, so a formatting pass never rewrites files you have not yet proven compile and pass. Running JUnit 5 via mvn test after the review, rather than before, is deliberate: the review may have produced fixes, and only the post-review tree is the one you intend to commit. Spotless then normalizes import order and whitespace across the changed classes so the commit contains logic, not style churn. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, so once mvn test is green and Spotless has run, the staging and commit can be done in the same session. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so `mvn test` can be allowed while the commit itself stays on ask. ## Steps 1. Produce the working diff with Atlas's bash tool and read it end to end, including `pom.xml` and `build.gradle`, not just the classes you remember touching. 2. Check git status through Atlas for untracked files, such as a new `src/test/java/.../OrderServiceTest.java` that was never added and would be invisible to CI. 3. Read each changed Java file in full with the read tool, checking the edit against the class's other methods, its equals and hashCode, and its overrides. 4. Grep the changed files for debugging leftovers you introduced: System.out.println, printStackTrace, a JUnit 5 @Disabled, and commented-out method bodies. 5. If a change should not have been made, use Atlas's session revert, which restores from a snapshot and asserts the session is not busy first. 6. Fix what the review turned up with the edit tool, reviewing the unified diff Atlas surfaces before each write. 7. Run JUnit 5 via mvn test through bash and confirm the suite is green on the post-review tree. 8. Run Spotless through bash so the commit contains logic rather than import-order churn, then stage and commit. ## FAQ ### how to review my own git diff before committing java Have Atlas produce the working diff with bash and read it end to end, then read each changed Java file in full so the edit is checked against the class it lives in. Grep for debug leftovers, then run JUnit 5 via mvn test and Spotless before committing. ### atlas revert a change it made to my java code Atlas snapshots file changes as git patches, and the session revert flow restores from those snapshots rather than requiring a hand-revert. Revert refuses to run on a busy session, which prevents a half-written turn from being rolled back mid-flight. ### why does my java build pass but the test never ran A JUnit 5 @Disabled annotation added to make `mvn test` go green will report a passing build while skipping the test entirely. Grep your working diff for @Disabled before committing, since it is the most common self-inflicted false green in a Java repo. ### does atlas check pom.xml changes in my diff Yes, if you read the whole diff. Maven build-file changes are the easiest thing to miss in a Java review and among the most consequential, so include `pom.xml` and `build.gradle` when reading the diff rather than only the classes under `src/main/java`. ### can atlas commit my java change for me Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf. Every tool call is permission-gated against allow, ask, and deny rules first, so you can allow `mvn test` while keeping the commit itself on ask. ### should i run spotless before or after mvn test Run JUnit 5 via mvn test first, then Spotless. Formatting a tree you have not yet proven compiles and passes just adds noise to a build you may still need to change. Spotless last keeps the commit focused on logic. ### atlas revert says session is busy Session revert asserts the session is not busy before it runs. That guard exists so a half-written turn is not rolled back mid-flight. Wait for the current turn to finish, then revert from the snapshot. ### how does atlas know what my java class does around my edit Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so when it reads a class it sees real declaration boundaries. It also searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion when it needs callers outside the file. --- Canonical HTML: https://runatlas.sh/resources/stacks/self-review-a-working-diff-before-committing-in-java Source of truth: aeo_pages row `/resources/stacks/self-review-a-working-diff-before-committing-in-java` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.