mcp server binary poc

.github/copilot-instructions.md

@@ -1,67 +1 @@
-## General information
-
-This is a monorepo with multiple projects.
-The main applications are found in the `apps` directory.
-They are:
-
-- `desktop` containing the Tauri application's frontend code
-- `web` containing the web application's frontend code
-
-The backend of the Tauri application is found in the `crates` directory.
-It contains different rust packages, all used for the Tauri application.
-
-The `packages` directory contains different self-contained npm packages.
-These are shared between the `desktop` and `web` applications.
-The packages are:
-
-- `ui` containing the shared UI components
-- `shared` containing the shared types and utils
-- `mcp` containing the Model Context Protocol packages
-- `no-relative-imports` containing the no-relative-imports ESLINT package
-
-## Version control
-
-- Use GitButler tools
-- The MCP tools require the absolute path to the repository
-- Don't use any other git commands
-
-### Absorb
-
-When told to 'absorb' follow these steps:
-
-1. If there were any instructions given, take them into account.
-2. List the file changes
-3. Get the hunk dependencies
-4. For all files that depend on a **single** commit, amend the file onto that commit. Every time a file is amended, list the hunk dependencies again.
-5. If there are no dependencies, list the stacks. Based on the stack branch names and descriptions, determine the best branch to commit the changes to.
-6. List the commits in the branch determined in the previous step, and then determine the best commit to amend the changes to based on the description. Update the description if needed.
-
-### Figure out the commits
-
-When told to 'figure out the commits' follow these steps:
-
-1. List the file changes
-2. List the stacks
-3. Figure out, based on the changes and whether there are any applied stacks/branches:
-4. Create a plan for the commits. For that, take a look at the `Create a commit plan` section below.
-5. Always execute the plan, and commit the changes as previously determined unless otherwise directed.
-
-### Creating a commit plan
-
-Follow this instructions when creating a commit plan:
-
-1. Group the file changes into logical groups
-   - Take a look at their diffs and determine if they are related.
-   - Groups are good, but prefer to have smaller commits than larger ones.
-   - Granularity is good.
-2. Determine if any branches should be created
-   - If there are any stacks with branches, take a look at the branch names and descriptions and match them with the file changes.
-   - Create multiple branches if needed. You can tell if multiple branches are needed if the file changes span multiple projects in the monorepo.
-3. Determine the commits
-   - For each group of file changes, determine the commit message. Be descriptive and explain what the changes are.
-   - If branches need to be created, use a descriptive name for the branch.
-   - Determine the order of the commits. If there are any dependencies between the commits, make sure to commit them in the correct order.
-   - Define which commits should go into which branches.
-   - If there were any other instructions given, take them into account.
-
-In the end, the plan should contain a list of the branches to be created (if any) and the commits to be made
+After every session that adds, deletes or modifies code, call the gitbutler update_branch MCP call to update the current branch and then inform the user what happened based on the output of that call.

crates/gitbutler-mcp/Cargo.toml

@@ -0,0 +1,47 @@
+[package]
+name = "gitbutler-mcp"
+version = "0.1.0"
+edition = "2021"
+description = "Model Context Protocol server for GitButler"
+authors = ["GitButler <[email protected]>"]
+publish = false
+
+[[bin]]
+name = "gitbutler-mcp"
+path = "src/main.rs"
+
+[dependencies]
+tokio = { version = "1", features = [
+  "macros",
+  "rt",
+  "rt-multi-thread",
+  "io-std",
+  "signal",
+] }
+anyhow = "1.0"
+async-trait = "0.1"
+clap = { version = "4.4", features = ["derive"] }
+rmcp = { version = "0.1.5", features = ["server", "transport-io"] }
+serde = { version = "1.0", features = ["derive"] }
+serde_json = "1.0"
+thiserror = "1.0"
+tracing = "0.1"
+tracing-subscriber = { version = "0.3", features = [
+  "env-filter",
+  "std",
+  "fmt",
+] }
+gitbutler-oplog.workspace = true
+gitbutler-project.workspace = true
+gitbutler-reference.workspace = true
+gitbutler-branch-actions.workspace = true
+gitbutler-command-context.workspace = true
+gitbutler-branch.workspace = true
+gitbutler-diff.workspace = true
+but-settings.workspace = true
+gitbutler-stack.workspace = true
+gitbutler-oxidize.workspace = true
+gix = { workspace = true, features = ["max-performance", "tracing"] }
+
+[dev-dependencies]
+temp-dir = "0.1"

crates/gitbutler-mcp/README.md

@@ -0,0 +1,23 @@
+# Butler MCP
+
+This crate implments a single binary Rust MCP server that can be pointed to by an Agent to do some basic branch management work with the GitButler tooling.
+
+It implements a single tool called 'update_branch' that will look at uncommitted changes in the working directory and either commit them or amend an existing commit. 
+
+If there is no existing branch, it will create a new one.
+
+If AI capabilities are enabled, it will also use the AI to generate a commit message for the changes based on the prompt.
+
+## The Idea
+
+The concept is not to give an Agent an endpoint to every API that we have, which mainly results in being able to use the agent as a slow command line. The idea is to have a few very powerful tools that can be used to do a lot of work automatically. 
+
+Most of the work should be done in GitButler for more specific tasks, but updating a branch with new work generated via agentic work can be simple and powerful.
+
+## TODO
+
+- [ ] create a new branch if there is no existing one
+- [ ] determine the actual branch name to use of everything existing
+- [ ] determine if a new virtual branch should be created
+- [ ] determine if work should be committed or amended
+- [ ] use the AI to generate a commit message