feat: Add programmatic interactive rebase operations (squash, fixup, drop, autosquash)

[AntoineMontane]

Summary

Add high-level MCP tools for common interactive rebase operations that don't require TTY/editor interaction. This enables LLM agents to programmatically clean up commit history.

Motivation

Interactive rebase (git rebase -i) is essential for maintaining clean git history, but it requires an interactive editor session. LLM agents need programmatic access to these operations for workflows like:

• Squashing WIP commits before PR
• Applying fixup commits
• Removing accidental/debug commits
• Auto-arranging fixup!/squash! commits

Proposed MVP Scope

Operation	Description
squash	Combine N commits into one, concatenate messages
fixup	Combine N commits, discard fixup commit messages
drop	Remove specific commits from history
autosquash	Auto-arrange fixup!/squash! commits via --autosquash

Technical Approach

Use GIT_SEQUENCE_EDITOR environment variable to inject a script that writes the desired rebase todo file, enabling non-interactive automation:

GIT_SEQUENCE_EDITOR=/tmp/rebase-script.sh git rebase -i <upstream>

The script generates the appropriate todo file content (pick/squash/fixup/drop lines) based on the requested operation.

---

Design Questions

We'd appreciate input on the following design decisions before implementation:

1. Tool Design

Option A: Single tool with action parameter

git_rebase_interactive({ action: 'squash', commits: [...] })

Option B: Separate specialized tools

git_squash({ commits: [...] })
git_fixup({ targetCommit: '...', fixupCommit: '...' })
git_drop({ commits: [...] })

Option C: Both (single tool + convenience aliases)

2. API Design for Commit Selection

Option A: Commit range syntax

{ range: 'HEAD~3..HEAD' }  // squash last 3 commits

Option B: Explicit commit list

{ commits: ['abc123', 'def456', 'ghi789'] }

Option C: Count-based

{ count: 3 }  // squash last 3 commits into one

3. Commit Message Handling (for squash)

• Auto-concatenate: Join all commit messages with separator
• User-provided: Require newMessage parameter
• First commit: Use first commit's message by default
• Configurable: Option to choose behavior

4. Safety Checks

Which safeguards should be enforced?

• Require clean working directory
• Warn if commits are already pushed to remote
• Block operations on protected branches
• Require explicit confirmation for destructive operations

5. Conflict Handling

When rebase encounters conflicts:

• Option A: Return conflict state, expect user to resolve + call git_rebase --continue
• Option B: Automatically abort and return error
• Option C: Configurable via parameter

6. Naming Convention

Preferred tool naming:

• git_rebase_interactive (generic)
• git_rebase_squash / git_rebase_fixup (namespaced)
• git_squash / git_fixup (short)

---

Implementation Plan

Once design is approved, implementation touches:

1. Types (src/services/git/types.ts) - New options/result types
2. Service layer (src/services/git/providers/cli/operations/branches/) - New operation functions
3. Utilities (src/services/git/providers/cli/utils/) - Todo file builder, editor script generator
4. Provider (src/services/git/providers/cli/CliGitProvider.ts) - New method(s)
5. Interface (src/services/git/core/IGitProvider.ts) - Interface update
6. Tool(s) (src/mcp-server/tools/definitions/) - New tool definition(s)
7. Tests - Unit + integration tests

Ready to Implement

We have a contributor ready to implement this feature once the design is approved. Looking forward to your feedback!

---

/cc @cyanheads