update
Scannednpx machina-cli add skill technicalpickles/pickled-claude-plugins/update --openclawGit Update
Overview
Update your current branch with changes from the upstream branch, intelligently resolving conflicts when they occur.
Announce: "Using git:update to sync your branch with upstream..."
Philosophy:
- Merge (not rebase) to preserve history
- Understand intent behind conflicting changes
- Resolve autonomously, present for approval before committing
When to Use
- User says "update", "sync", "pull in latest", "merge main"
- PR has conflicts that need resolving
- Branch is behind upstream and needs updating
- User wants to incorporate recent changes from main/master
Workflow: Detect Upstream
Step 1: Try tracking branch
git rev-parse --abbrev-ref @{upstream} 2>/dev/null
If this succeeds, use the result (e.g., origin/main).
Step 2: Fall back to PR base branch
If no tracking branch:
gh pr view --json baseRefName -q '.baseRefName' 2>/dev/null
If this succeeds, use origin/{result}.
Step 3: Ask user if neither works
If both fail, use AskUserQuestion:
I couldn't detect an upstream branch for this branch.
Which branch should I merge from?
(A) main
(B) master
(C) Other - I'll specify
Workflow: Fetch and Merge
Step 1: Fetch latest
git fetch origin
Step 2: Check if update needed
git rev-list --count HEAD..{upstream}
If count is 0, report "Already up to date with {upstream}" and stop.
Step 3: Attempt merge
git merge {upstream} --no-edit
Step 4: Branch on result
| Exit Code | Meaning | Action |
|---|---|---|
| 0 | Clean merge | Push and report success |
| 1 | Conflicts | Proceed to conflict resolution |
On clean merge:
git push
Report:
## Update Complete
Merged `{upstream}` into `{current-branch}`
{N} commits pulled in
Pushed to origin
Workflow: Conflict Resolution
Step 1: Inventory conflicts
git diff --name-only --diff-filter=U
Step 2: For each conflicted file, gather context
Read the conflict:
cat {file} # Shows conflict markers
Understand "ours" (your branch):
git log --oneline -5 HEAD -- {file}
git show HEAD:{file} # Your version
Understand "theirs" (upstream):
git log --oneline -5 {upstream} -- {file}
git show {upstream}:{file} # Their version
Get commit messages for context:
# What your commits were doing
git log --format="%s%n%b" HEAD...$(git merge-base HEAD {upstream}) -- {file}
# What upstream commits were doing
git log --format="%s%n%b" {upstream}...$(git merge-base HEAD {upstream}) -- {file}
Step 3: Analyze each conflict
For each conflict, determine the type:
| Type | Description | Resolution Strategy |
|---|---|---|
| Independent | Changes to different parts of file | Keep both changes |
| Overlapping | Same area, different purposes | Blend changes thoughtfully |
| Contradictory | Mutually exclusive changes | Present options to user |
Analysis approach:
- Read both versions and the conflict markers
- Use commit messages to understand intent
- Identify what each side was trying to accomplish
- Determine if changes can coexist or need reconciliation
Step 4: Resolve conflicts
For independent changes:
- Identify which hunks belong to each side
- Structure the file to include both changes appropriately
For overlapping changes:
- Understand the newer pattern/approach (usually upstream)
- Apply your changes using the newer approach
- Example: If upstream refactored a function, adapt your additions to the new structure
For contradictory changes:
- Do not auto-resolve
- Present both options to user with context
Step 5: Present for approval
After resolving, show summary:
## Conflict Resolution Summary
Merged `main` into `feature/my-branch`
### {filename}
**Your changes:** {1-2 sentence summary of what your commits did}
**Upstream changes:** {1-2 sentence summary of what upstream commits did}
**Resolution:** {1-2 sentence explanation of how resolved}
```diff
{Show key parts of the resolution}
[Repeat for each file]
Verification:
- No conflict markers remain
- File parses correctly (if applicable)
Does this resolution look correct? (A) Yes, commit and push (B) Let me review/adjust manually (C) Show me more context on a specific file
Use AskUserQuestion with these options.
## Workflow: Verification & Completion
### Step 1: Verify no conflict markers
```bash
grep -rn "^<<<<<<< \|^=======$\|^>>>>>>> " {resolved_files}
If any found, resolution is incomplete - fix before proceeding.
Step 2: Syntax verification (where practical)
| File Type | Check |
|---|---|
.json | python -m json.tool {file} > /dev/null |
.yaml/.yml | python -c "import yaml; yaml.safe_load(open('{file}'))" |
.ts/.tsx | npx tsc --noEmit {file} (if tsconfig exists) |
.py | python -m py_compile {file} |
Step 3: Commit and push
git add {resolved_files}
git commit -m "Merge {upstream} into {branch}
Resolved conflicts in:
$(for f in {resolved_files}; do echo "- $f"; done)"
git push
Step 4: Report completion
## Update Complete
Merged `{upstream}` into `{branch}`
Resolved {N} conflict(s):
- {file1}
- {file2}
Pushed to origin. PR should now be mergeable.
Edge Cases
| Situation | Handling |
|---|---|
| Binary file conflicts | Flag for manual resolution: "Binary file {file} has conflicts - please resolve manually" |
| Submodule conflicts | Flag with guidance: "Submodule {name} has conflicts. Usually: accept upstream version or update to specific commit" |
| Someone else's branch | Check with gh pr view --json author -q '.author.login'. If not current user, warn: "This is @{author}'s branch. They should be aware of changes. Continue?" |
| Too complex to resolve | Present what was understood, mark specific hunks as needing manual attention |
| Merge already in progress | Detect with git status showing "You have unmerged paths". Offer to continue or abort. |
Quick Reference
| Command | Purpose |
|---|---|
git rev-parse --abbrev-ref @{upstream} | Get tracking branch |
git merge --abort | Cancel in-progress merge |
git diff --name-only --diff-filter=U | List conflicted files |
git checkout --ours {file} | Take your version entirely |
git checkout --theirs {file} | Take upstream version entirely |
git show HEAD:{file} | Your version of file |
git show MERGE_HEAD:{file} | Upstream version of file |
Related Skills
git:commit- Commit practices (used after resolution)git:pull-request- Creating/updating PRsgit:triage- Overview of work state
Source
git clone https://github.com/technicalpickles/pickled-claude-plugins/blob/main/plugins/git/skills/update/SKILL.mdView on GitHub Overview
Update your current branch with changes from the upstream branch using a merge-based workflow to preserve history. It fetches updates, attempts a merge, and resolves conflicts intelligently before presenting the result for your approval.
How This Skill Works
First, the skill detects the upstream branch by checking for a tracking branch, then falls back to the PR base or prompts the user. It then fetches from origin, checks whether an update is needed with git rev-list, and performs git merge {upstream} --no-edit. If conflicts occur, it inventories the conflicting files, gathers context of ours and theirs, analyzes intent, and resolves conflicts according to predefined strategies before pushing.
When to Use It
- User asks to update, sync, pull in latest, or merge main
- Pull requests have conflicts that require resolution
- Your branch is behind upstream and needs updating
- You want to incorporate recent changes from main/master
- You prefer a merge-based history preservation over rebasing
Quick Start
- Step 1: Detect Upstream: Try git rev-parse --abbrev-ref @{upstream} 2>/dev/null; if needed fall back to gh pr view --json baseRefName -q '.baseRefName' 2>/dev/null; otherwise ask the user to specify
- Step 2: Fetch Latest: git fetch origin
- Step 3: Merge and Resolve: git merge {upstream} --no-edit; if conflicts occur, enter the conflict resolution flow and then push when resolved
Best Practices
- Prefer merge (not rebase) to preserve history
- Always fetch upstream before merging
- Check if update is needed with git rev-list HEAD..{upstream}
- Inventory conflicts and gather context for each file
- Present a concise summary and obtain approval before final push
Example Use Cases
- Feature branch updated after upstream changes with a clean merge and push
- Pull request with conflicts resolved automatically where possible
- Branch behind main synced to latest commits
- Incorporate several commits from main/master into a feature branch
- Conflicts resolved by presenting options to the user when necessary