Git Rollback & Bisect
Relevant source files
The following files were used as context for generating this wiki page:
The Git Rollback & Bisect system in M31 Autonomous (M31A) provides a robust mechanism for managing state revisions and diagnosing regressions within an automated coding workflow. Since M31A operates on an atomic commit-per-task model, these utilities allow the agent to revert to known-good states or systematically identify the specific commit that introduced a failure during the Verify Phase.
This system is integrated into the core engine to support "self-healing" behaviors. When automated tests or build checks fail, the bisect module can traverse the session's commit history to find the offending change, while the rollback module manages the safety of the working directory by stashing uncommitted changes before performing resets.
Sources: README.md:104-125, internal/engine/workflow/ship.go:44-55
Git Rollback System
The rollback system manages the transition between different git refs, supporting three primary reset strategies: Soft, Hard, and Safe. It is designed to ensure that no developer work is lost during an automated reset by leveraging git stashing.
Reset Strategies
| Strategy | Description | Behavior |
|---|---|---|
| Soft Reset | Moves HEAD to a target commit while keeping all changes staged in the index. | Preserves work-in-progress; useful for re-committing. |
| Hard Reset | Moves HEAD and overwrites both the index and the working tree to match the target. | Discards all changes; used to return to a strictly clean state. |
| Safe Reset | A Hard Reset wrapped in automated stashing/popping logic. | Protects uncommitted changes before performing a destructive reset. |
Sources: internal/engine/rollback/rollback_test.go:138-164, internal/engine/rollback/rollback_test.go:215-238
Working Directory Safety
Before executing a reset that could overwrite data, the system performs a "dirty check" on the working directory. If uncommitted changes, staged files, or deleted tracked files are detected, the system automatically creates a temporary stash.
The diagram shows the logic flow for protecting uncommitted changes during reset operations.
Sources: internal/engine/rollback/rollback_test.go:189-210, internal/engine/rollback/rollback_test.go:375-395
Implementation Details
The system relies on the internal/integrations/git wrapper to execute shell-level git commands. Key internal functions include:
Chain(limit): Retrieves a list of recent commits (defaulting to 20) with associated diffs for previewing.Preview(hash): Computes the diff between a specific commit and HEAD, capped at 50,000 characters to prevent buffer overflows.HasUncommittedChanges(): Detects untracked, modified, or staged files.
Sources: internal/engine/rollback/rollback_test.go:27-55, internal/engine/rollback/rollback_test.go:111-136
Git Bisect Module
The Bisect module is an automated wrapper around git bisect, used specifically when the Verify Phase fails. It performs a binary search through the commit history to isolate the "first bad commit."
Bisect Workflow Logic
The Run method orchestrates the bisect process between a sessionStartHash (known good) and the current headHash (known bad). It utilizes a provided checkFn—usually a build or test command—to automate the classification of each step.
This sequence shows how the bisect engine automates the manual git bisect process by invoking test runners.
Sources: internal/engine/bisect/bisect.go:53-113
Log Parsing and Diff Extraction
Once a regression is isolated, the module parses the git bisect log to extract the offending commit's hash. It then automatically generates a diff (git diff hash^..hash) to provide the agent with exact context on what changed in the broken commit. This result is used in the Self-Heal loop.
Sources: internal/engine/bisect/bisect.go:121-165, internal/engine/workflow/prompts/self-heal.md:115-119
Core Git Integrations
Both systems depend on a comprehensive git wrapper that abstracts complex CLI operations into Go methods.
Key Integration Methods
| Method | CLI Equivalent | Purpose |
|---|---|---|
StatusPorcelain() | git status --porcelain | Structured, machine-readable file status. |
CommitStaged(msg) | git commit -m | Atomic commit of current index. |
DiffRefs(h1, h2) | git diff h1..h2 | Comparison between two specific hashes. |
RevParse(ref) | git rev-parse --ref | Resolving HEAD or other refs to full hashes. |
StashPush/Pop() | git stash push/pop | Temporary storage of uncommitted changes. |
Sources: internal/integrations/git/git_extra_test.go:14-29, internal/integrations/git/git_extra_test.go:210-228, internal/integrations/git/git_test.go:180-210
Commit Sanitization
M31A enforces sanitization on commit messages used during automated rollbacks and ships. It strips newlines, removes leading/trailing spaces, and truncates messages to 200 characters (appending ...) to maintain a clean git log and prevent shell injection or formatting issues in the TUI.
Sources: internal/integrations/git/git_extra_test.go:455-475
Conclusion
The Git Rollback and Bisect modules form the safety net of the M31 Autonomous engine. By providing automated state recovery and precise bug isolation, these systems allow the AI agent to operate with high degrees of autonomy while maintaining the integrity of the project's version history. The combination of safe resets and automated bisecting ensures that even when the agent makes a mistake, the path to recovery is programmatic and reliable.