commit-all

name	commit-all
description	Commit current changes. Use when: committing work, grouping changes into atomic commits, staging and committing, creating conventional commits. Groups related changes into well-scoped atomic commits with clear messages.

Commit All

Analyze the current working tree and stage+commit changes in well-scoped, atomic commits using conventional commit messages.

When to Use

• You have uncommitted changes (staged or unstaged) and want to commit them
• You want changes grouped logically rather than as one big commit
• After finishing a task or phase and need to commit the results

Procedure

1. Inspect the Working Tree

Run git status and git diff --stat to understand what has changed. If there are staged changes, also run git diff --cached --stat.

2. Group Changes into Atomic Commits

Analyze the changed files and group them by logical unit of work. Grouping heuristics:

• Files in the same module that implement a single feature → one commit
• Test files paired with their implementation → same commit as the implementation
• Pure refactors or renames → separate commit
• Documentation-only changes → separate commit
• Config/build changes (Cargo.toml, clippy.toml, etc.) → separate commit unless tightly coupled to a feature
• Unrelated bug fixes → separate commit each

Each commit should be independently correct — it should compile and tests should pass.

3. Create Commits

For each group, in dependency order (so the repo compiles after each commit):

1. Stage the relevant files: git add <files>
2. Write a conventional commit message following this format:

   <type>(<scope>): <short description>
   
   <optional body explaining what and why>
   

3. Commit: git commit -m "<message>"

Conventional Commit Types

Type	Use for
feat	New feature or capability
fix	Bug fix
refactor	Code change that neither fixes a bug nor adds a feature
test	Adding or updating tests
docs	Documentation only
chore	Build, CI, tooling, or dependency changes
perf	Performance improvement

Scope

Use the module or area name (e.g., algo, engine, io, remote, cli, wal, sstable, memtable).

4. Verify

After all commits, run git log --oneline -n <number_of_commits> to confirm the result looks clean and logical.

Constraints

• Follow the project's version control rules from AGENTS.md:
  • Concise, well-scoped, atomic commits
  • Conventional commit messages
  • Never commit debug println! or dbg! macros
  • Never commit credentials or sensitive data
• If a change touches both implementation and its tests, include both in the same commit
• Prefer more granular commits over fewer large ones, but don't split changes that only make sense together