-
Notifications
You must be signed in to change notification settings - Fork 109
feat(git): add git issue resolve slash command #115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: radeore The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Hi @radeore. Thanks for your PR. I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/ok-to-test |
|
@radeore: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/ok-to-test |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
WalkthroughThis PR introduces a new Git plugin command Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Nitpick comments (2)
plugins/git/commands/branch-resolve.md (2)
14-25: Minor phrasing improvement needed in description.Line 15 has awkward wording: "enabling developers to smoothly pulling or pushing code." Should be "enabling developers to smoothly pull or push code" or "helping developers pull or push code smoothly."
Consider also the static analysis note about verb choice (line 15 shows "pulling" could be improved).
Apply this diff to improve readability:
-The `git:branch-resolve` command is an AI-powered git troubleshooting assistant that analyzes and resolves branch-related issues, enabling developers to smoothly pulling or pushing code. It helps identify and fix common problems such as: +The `git:branch-resolve` command is an AI-powered git troubleshooting assistant that analyzes and resolves branch-related issues, helping developers pull or push code smoothly. It helps identify and fix common problems such as:
85-113: Convert emphasis-formatted issue markers to proper markdown headings.Lines 85, 90, 95, 100, 105, 110 use bold emphasis (
**Issue: ...) to mark diagnostic issue patterns, but these should be proper markdown headings for document structure. This improves machine-readability, navigation, and follows markdown best practices.Apply this diff to convert the issues to headings:
### 2. Diagnosis Phase - Identify Issues Pattern match against common scenarios: -**Issue: Diverged Branch** +#### Issue: Diverged Branch - Symptoms: ... - Detection: ... - Cause: ... -**Issue: Merge Conflicts** +#### Issue: Merge ConflictsApply the same pattern to all issue markers (Rejected Push, Missing Upstream, Uncommitted Changes, Detached HEAD).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting
📒 Files selected for processing (4)
PLUGINS.md(1 hunks)docs/data.json(1 hunks)plugins/git/README.md(1 hunks)plugins/git/commands/branch-resolve.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
plugins/git/commands/branch-resolve.md
[style] ~15-~15: Consider using a different verb for a more formal wording.
Context: ... or pushing code. It helps identify and fix common problems such as: - Diverged bra...
(FIX_RESOLVE)
[style] ~415-~415: The words ‘Explanation’ and ‘explain’ are quite similar. Consider replacing ‘explain’ with a different word.
Context: ...rmation - Explanation first: Always explain what commands will do and their implica...
(VERB_NOUN_SENT_LEVEL_REP)
🪛 markdownlint-cli2 (0.18.1)
plugins/git/commands/branch-resolve.md
10-10: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
26-26: Bare URL used
(MD034, no-bare-urls)
85-85: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
90-90: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
95-95: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
100-100: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
105-105: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
110-110: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
229-229: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
233-233: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
265-265: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
269-269: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
296-296: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
300-300: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
343-343: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
347-347: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
381-381: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
385-385: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (6)
docs/data.json (1)
16-21: Command registry entry looks good.The new command is properly registered in the JSON structure with clear description and consistent formatting.
PLUGINS.md (1)
57-57: Markdown entry is consistent and properly positioned.The command listing follows the established pattern and is correctly placed in alphabetical order.
plugins/git/README.md (1)
7-9: README entry is concise and follows established pattern.The new command summary is properly formatted and consistent with other Git plugin commands.
plugins/git/commands/branch-resolve.md (3)
115-193: Solution strategies are comprehensive and safety-conscious.The proposed solutions for each issue type are well-structured, technically sound, and include appropriate safety warnings. The preference for
--force-with-leaseover--force(line 130) is an excellent safety practice. The 3 options for uncommitted changes (commit, stash, discard) provide good flexibility.
194-216: Execution and safety guidelines are thorough and best-practice-aligned.The five-step execution flow (explain → warn → confirm → execute → verify) is the correct approach for handling destructive operations. The safety guidelines comprehensively cover critical git workflows:
- Prevents dangerous force-push scenarios to protected branches
- Enforces user confirmation for destructive operations
- Recommends
--force-with-leaseover--force(better safety)- Suggests backup strategies for complex operations
- Emphasizes educational value to prevent future issues
This is exactly what an AI assistant should require before executing risky commands.
410-419: Arguments and Safety Considerations sections are well-defined.The optional
issue-descriptionargument is clearly documented. The Safety Considerations effectively summarize critical constraints:
- Protected operations requiring explicit confirmation
- Emphasis on explanation before execution
- Recommendation for safer alternatives
- Step-by-step execution with user control
Note: There's intentional (and appropriate) repetition between the Safety Guidelines section (lines 204-215) and Safety Considerations (lines 413-419). This summary reinforcement at the end of the document is helpful for quick reference.
| ```bash | ||
| # Working tree state | ||
| git status | ||
|
|
||
| # Branch information with tracking details | ||
| git branch -vv | ||
|
|
||
| # Remote configuration | ||
| git remote -v | ||
|
|
||
| # Current branch name | ||
| git branch --show-current | ||
| ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion | 🟠 Major
Add language specifier to all fenced code blocks.
All code blocks need explicit language identifiers for proper markdown rendering. The blocks starting at lines 36, 50, 59, 71 (and more throughout the file) are missing the bash language tag.
Example fix for lines 36-48:
-**Check repository status:**
-```
+**Check repository status:**
+```bashApply this same fix to all 13+ code blocks in the file that are missing language specifiers. Lines affected: 36, 50, 59, 71 (in Analysis Phase), 122, 135, 152, 162, 172, 186 (in Solution Strategy), and all example output blocks (229, 233, 265, 269, 296, 300, 343, 347, 381, 385).
🤖 Prompt for AI Agents
In plugins/git/commands/branch-resolve.md around lines 36 to 48, several fenced
code blocks are missing language specifiers; update each affected
triple-backtick fence to include the appropriate language (e.g., ```bash) so
markdown renders correctly. Apply the same change to all other reported
locations (lines 50, 59, 71, 122, 135, 152, 162, 172, 186, and the example
output blocks at 229, 233, 265, 269, 296, 300, 343, 347, 381, 385), ensuring
every fenced code block has a language tag (use bash for shell snippets) and
keep surrounding text unchanged.
| ## Examples | ||
|
|
||
| ### 1. Basic usage (analyze current issues) | ||
| ``` | ||
| /git:branch-resolve | ||
| ``` | ||
| Output: | ||
| ``` | ||
| ## Diagnosis | ||
| Your branch has diverged from the remote. You have 3 local commits that aren't on | ||
| the remote, and the remote has 2 commits that you don't have locally. | ||
|
|
||
| ## Current State | ||
| - Branch: feature-auth | ||
| - Local commits ahead: 3 | ||
| - Remote commits behind: 2 | ||
| - Working tree: clean (no uncommitted changes) | ||
|
|
||
| ## Recommended Solution | ||
|
|
||
| I recommend using **rebase** to create a cleaner, linear history: | ||
|
|
||
| git pull --rebase origin feature-auth | ||
|
|
||
| This will: | ||
| 1. Temporarily remove your 3 local commits | ||
| 2. Apply the 2 remote commits to your branch | ||
| 3. Replay your 3 commits on top | ||
|
|
||
| Alternative: git pull (creates merge commit, preserves all history) | ||
|
|
||
| ## Risks & Considerations | ||
| - Rebase rewrites commit history (changes commit SHAs) | ||
| - Safe because your working tree is clean | ||
|
|
||
| Proceed with rebase? (y/n) | ||
| ``` | ||
|
|
||
| ### 2. With specific issue context | ||
| ``` | ||
| /git:branch-resolve "can't push my changes" | ||
| ``` | ||
| Output: | ||
| ``` | ||
| ## Diagnosis | ||
| Your push was rejected because the remote branch has commits that you don't | ||
| have locally. This protects against overwriting others' work. | ||
|
|
||
| ## Current State | ||
| - Branch: main | ||
| - Remote has new commits: yes | ||
| - Local commits to push: yes | ||
| - Working tree: clean | ||
|
|
||
| ## Recommended Solution | ||
|
|
||
| Safe resolution: | ||
| 1. git fetch origin | ||
| 2. git pull origin main | ||
| 3. git push origin main | ||
|
|
||
| If step 2 creates conflicts, I'll help resolve them. | ||
|
|
||
| DO NOT force push - this would overwrite others' work! | ||
|
|
||
| ## Execution | ||
| Proceeding with safe pull and push sequence... | ||
| ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
Examples are well-structured and demonstrate safety messaging effectively.
The five scenarios are realistic, cover the main issue types, and show how the command provides both diagnosis and educational context. The emphasis on safety (e.g., "DO NOT force push" on line 289) in example outputs is excellent. However, all example output code blocks are missing language specifiers (lines 229, 233, 265, 269, 296, 300, 343, 347, 381, 385). Add text or bash language identifiers to all fenced blocks showing command output or expected interaction. Also address the bare URL on line 26: wrap the reference in a markdown link format like [man-pages reference](https://man7.org/...).
🏁 Script executed:
#!/bin/bash
# Verify the review comment issues in branch-resolve.md
FILE="plugins/git/commands/branch-resolve.md"
echo "=== Checking line 26 for bare URL ==="
sed -n '20,32p' "$FILE"
echo ""
echo "=== Checking for missing language specifiers in code blocks ==="
# Search for code blocks to identify those missing language tags
grep -n '```' "$FILE" | head -20Length of output: 256
---
🏁 Script executed:
```shell
#!/bin/bash
# Search for the branch-resolve.md file
echo "=== Searching for branch-resolve.md ==="
fd -e md -i branch-resolve
echo ""
echo "=== Alternative: search for all .md files in plugins/git/commands ==="
fd -e md plugins/git/commands
Length of output: 535
🏁 Script executed:
#!/bin/bash
# Inspect the file for the two issues
FILE="plugins/git/commands/branch-resolve.md"
echo "=== Checking line 26 context for bare URL ==="
sed -n '20,35p' "$FILE"
echo ""
echo "=== Checking code block lines for missing language specifiers ==="
for line_num in 229 233 265 269 296 300 343 347 381 385; do
echo "--- Line $line_num context ---"
sed -n "$((line_num-1)),$((line_num+1))p" "$FILE"
doneLength of output: 1444
Add language specifiers to all code block fences and wrap the bare URL reference in markdown link format.
The file contains 10 code blocks (lines 229, 233, 265, 269, 296, 300, 343, 347, 381, 385) missing language identifiers on their opening fences. Add text or bash after the opening ``` on each block. Additionally, line 26 contains a bare URL: wrap https://man7.org/linux/man-pages/man7/man-pages.7.html#top_of_page in markdown link format like [man-pages reference](https://man7.org/linux/man-pages/man7/man-pages.7.html#top_of_page).
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
229-229: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
233-233: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
265-265: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
269-269: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In plugins/git/commands/branch-resolve.md (note: code fences referenced around
lines 229, 233, 265, 269, 296, 300, 343, 347, 381, 385 and a bare URL at line
26), add explicit language identifiers to each code block opening fence (use
bash for shell/git snippets and text for plain output blocks) so every ```
becomes either ```bash or ```text as appropriate, and replace the bare URL at
line 26 with a markdown link like [man-pages
reference](https://man7.org/linux/man-pages/man7/man-pages.7.html#top_of_page).
stbenjam
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My biggest concern is about anything telling Claude to push, or worse that it should try to fix a push problem. Even with guidance not to use --force models do not always follow instructions 100%.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have some examples of showing this works? How does it know what the problem on the branch is without you telling it? Obviously merge conflicts it can detect, but how does it know you intend to fix any of these:
- Push rejections (non-fast-forward errors)
- Missing upstream tracking branches
- Uncommitted changes blocking pull/merge/rebase operations
- Stale references or tracking issues
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stbenjam I have added example outputs for the mentioned git issue scenarios. Thanks!
| **Issue: Rejected Push** | ||
| - Symptoms: `git push` fails with "rejected" or "non-fast-forward" | ||
| - Detection: Remote has commits not in local history | ||
| - Cause: Remote branch moved ahead of local |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does it know this is a problem it should solve? I am a little nervous about coaching Claude that it should try to resolve any push problem itself. This seems a little risky
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main idea is the slash command helps identify any git issues on the current branch and then provides brief explanation about the problem/issue, then provides multiple options on how to resolve the issue and based on user inputs, it then proceeds with detailed steps on how to resolve the issue and with user's permission it does the changes (pull, rebase, push, etc.) to the branch. Also, user can opt to not allow claude to make changes, instead resolve issues by following the claude suggested solutions.
|
I wonder if instead of getting Claude to fix any problem it determines is present by its self, the output of the command is a plan - e.g written to a markdown file along with its reasoning. This can still provide value to an end user: it's worked out the problem and decided what it thinks should be done, but ultimately leaves the implementation to the end user? (who would thoroughly check it before following) |
|
Examples for the results produced for different scenarios by slash command without providing any input: 1. Push rejections (non-fast-forward errors) /git:branch-resolve is running… ● Diagnosis
Current State
Recommended Solution
What would you like to do with the uncommitted changes in test/extended/storage/general_csi.go?
∴ Thinking…
Now let's resolve the branch divergence. Your branch now has:
● ✓ Resolution Complete!
Current State:
Your testrun branch is in good shape. You have 2 commits ready to push when you're ready. |
|
2. Missing Upstream Tracking Branches:
● Diagnosis
Analysis
Recommended Solution Option 1: Set upstream and push in one commandgit push --set-upstream origin demo-test Option 2: Just set upstream (if already pushed)git branch --set-upstream-to=origin/demo-test
● ✓ Resolution Complete
Your branch is ready to go! |
|
3. Stale references and tracking issues:
● Diagnosis Current State
Issue Explanation
Recommended Solutions Switch to master or another appropriate branchgit branch --set-upstream-to=origin/master Or push to your fork and track itgit push -u origin another-stale-branch
|
Yes, this mainly help identifying the git issue and provide solution to resolve it and with user's permission it proceeds with the changes. Thanks! |
What this PR does / why we need it:
Add new git slash command (
/git:branch-resolve) that analyze and resolve git repository/branch issues (eg., conflicts, divergence, push/pull problems)The
git:branch-resolvecommand is an AI-powered git troubleshooting assistant that analyzes and resolves branch-related issues. It helps identify and fix common problems such as:Checklist:
🤖 Generated with Claude Code