Skip to content

Add patch-safe exact file update tool - #3232

Draft
jasonobrown wants to merge 4 commits into
github:mainfrom
jasonobrown:feature/patch-safe-file-update-v2
Draft

Add patch-safe exact file update tool#3232
jasonobrown wants to merge 4 commits into
github:mainfrom
jasonobrown:feature/patch-safe-file-update-v2

Conversation

@jasonobrown

Copy link
Copy Markdown

Summary

Adds apply_file_patch, a bounded exact-text update tool that lets the GitHub MCP server modify an existing UTF-8 file without requiring the MCP client/model to resend the entire replacement file.

Refs #3231.

Motivation

The existing create_or_update_file / push_files interfaces require complete replacement content. A real ~303 KB changelog update was truncated upstream of GitHub while only a small insertion was intended. The resulting branch commit was detected and discarded, but recovery required a separate local Git client.

This tool keeps the large file server-side and sends only the intended exact replacements through MCP.

Safety model

  • Requires an exact current branch expected_head_sha.
  • Requires the exact existing expected_blob_sha for the target file.
  • Each old_text must match exactly expected_occurrences times at that step; default is one.
  • No fuzzy patching or offset guessing.
  • Rejects empty match strings, no-op updates, symlinks, non-regular modes, non-UTF-8 data, oversized files, oversized patch payloads, and excessive edit counts.
  • Preserves regular/executable file mode.
  • Creates the replacement blob/tree/commit on the exact expected parent.
  • Advances the branch ref with force=false; concurrent branch movement fails non-fast-forward instead of overwriting it.
  • Existing workflow-file OAuth challenge behavior is preserved.

Initial limits are 4 MiB target file, 256 KiB aggregate old/new patch text, and 100 ordered edits.

Tests

Includes focused unit coverage for ordered exact replacement, occurrence-count mismatch, empty match rejection, no-op rejection, and patch-size bounding.

I could statically verify the go-github/v89 Git API call signatures available from repository/dependency source, but this execution environment cannot clone the complete public repository to run the full Go suite locally. This PR is therefore intentionally draft until repository CI/build/snapshot/documentation checks establish the exact integration result. I will address concrete CI findings without weakening the fail-closed contract.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant