Conversation
|
What version of git is shipping with msysgit. If these changes are going to go through to support msysgit they need to happen in a crossplatform way, and they currently are not. I don't use windows anymore, ever. We'll need to communicate a lot to make this happen. |
|
Yes sorry, it was more to help people to use your tool on windows and it is not expected to be merged. |
|
Thank you heaps for this! Scm_breeze is working on my windows machine now, this makes me very happy :D |
|
just wanted to mention that this fix worked for me on windows as well :) thanks! 👍 |
Thank you, it helpet alot. |
|
what worked for me is replacing |
|
@coderabbitai /review |
|
✅ Actions performedReview triggered.
|
📝 WalkthroughWalkthroughThis pull request fixes Windows compatibility issues and refactors git command execution. Changes include adding a Windows compatibility notice to documentation, removing variable interpolation from git command invocation, and rewriting branch detection logic to use Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
lib/git/branch_shortcuts.sh (1)
24-32: Use$_git_cmdconsistently instead of hardcodinggit.Line 25 hardcodes
gitwhile lines 18 and 37 rely on$_git_cmd. If$_git_cmdpoints to a wrapper (e.g., hub) or a non-PATH git, the numbered branch list will diverge from the list used by the fallback check and the exported shortcuts, causing inconsistent behavior.🔧 Suggested fix (reuse $_git_cmd safely)
- ruby -e "$( cat <<EOF - output = %x(git branch --color=always $@) + SCMB_GIT_CMD="$_git_cmd" ruby -e "$( cat <<'EOF' + git_cmd = ENV["SCMB_GIT_CMD"] || "git" + output = IO.popen([git_cmd, "branch", "--color=always", *ARGV], &:read) line_count = output.lines.to_a.size output.lines.each_with_index do |line, i| spaces = (line_count > 9 && i < 9 ? " " : " ") puts line.sub(/^([ *]{2})/, "\\\1\033[2;37m[\033[0m#{i+1}\033[2;37m]\033[0m" << spaces) end EOF -)" +)" -- "$@"
🤖 Fix all issues with AI agents
In `@lib/git/status_shortcuts.rb`:
- Around line 28-31: The branch-name regex is incorrectly excluding dots and
truncates names like release/1.0; in the git parsing block that sets git_branch
and `@branch` replace the pattern /^\* (?:Initial commit on )?([^ \.]+)/ with one
that allows dots (e.g. /^\* (?:Initial commit on )?([^ ]+)/) so `@branch` captures
the full branch name; keep the existing ahead/behind captures (`@ahead` and
`@behind`) as they already parse the [ahead/behind] info from git branch -v.
In `@README.markdown`:
- Line 3: Update the user-facing heading string "## /!\ this version contain a
fix to works with windows!" to a clear, grammatical notice; replace it with a
corrected sentence such as "## ⚠️ This version contains a fix to work on
Windows." — fix capitalization, verb agreement ("contains"), and wording ("to
work on Windows") and keep the warning emphasis (emoji or symbol) so readers
immediately understand it's a Windows compatibility fix.
| git_branch = `\git branch -v` #git_status_lines[0] | ||
| @branch = git_branch[/^\* (?:Initial commit on )?([^ \.]+)/, 1] | ||
| @ahead = git_branch[/^\*.*\[ahead ?(\d+).*\]/, 1] | ||
| @behind = git_branch[/^\*.*\[.*behind ?(\d+)\]/, 1] |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check if the file exists and read the relevant lines
if [ -f "lib/git/status_shortcuts.rb" ]; then
echo "File found. Reading lines 25-35:"
sed -n '25,35p' lib/git/status_shortcuts.rb
else
echo "File not found. Listing directory structure:"
find . -name "status_shortcuts.rb" -type f
fiRepository: scmbreeze/scm_breeze
Length of output: 512
🏁 Script executed:
# Test git branch -v vs -vv output to understand the difference
# We'll create a simple test to show what each command outputs
cat > /tmp/test_git_branch.md << 'EOF'
# Git branch output comparison
## git branch -v
Description: Shows branch names with the commit hash and commit subject
Example output format:Repository: scmbreeze/scm_breeze
Length of output: 155
🏁 Script executed:
# Test the regex patterns with various branch names
python3 << 'PYTHON_EOF'
import re
# Test cases for branch name extraction
branch_samples = [
"* main",
"* release/1.0",
"* feature/my.branch",
" develop",
"* (detached HEAD at abc1234)"
]
# Original regex from code: /^\* (?:Initial commit on )?([^ \.]+)/
original_pattern = r'^\* (?:Initial commit on )?([^ \.]+)'
# Suggested regex: /^\* (?:Initial commit on )?([^ ]+)/
suggested_pattern = r'^\* (?:Initial commit on )?([^ ]+)'
print("Testing branch name extraction patterns:\n")
print("Original regex: [^ \.]+ (excludes spaces AND dots)")
print("Suggested regex: [^ ]+ (excludes only spaces)\n")
for sample in branch_samples:
orig_match = re.search(original_pattern, sample)
sugg_match = re.search(suggested_pattern, sample)
orig_result = orig_match.group(1) if orig_match else "NO MATCH"
sugg_result = sugg_match.group(1) if sugg_match else "NO MATCH"
print(f"Input: {sample!r}")
print(f" Original [^ \.]+: {orig_result!r}")
print(f" Suggested [^ ]+: {sugg_result!r}")
if orig_result != sugg_result:
print(f" ⚠️ DIFFERS")
print()
PYTHON_EOFRepository: scmbreeze/scm_breeze
Length of output: 150
🌐 Web query:
git branch -v vs -vv output difference tracking upstream
💡 Result:
git branch -v and git branch -vv are both “verbose list” modes, but -vv adds more tracking/upstream detail.
git branch -v
Shows, for each local branch, the abbreviated commit id and the tip commit’s subject, and (if configured) the relationship to its upstream (e.g., ahead/behind). The upstream name itself may or may not be shown depending on Git version/config, but the intent is “verbose + upstream relationship”. [1]
git branch -vv
Everything from -v, plus:
- the name of the upstream branch (the branch it tracks), and
- the linked worktree path if the branch is checked out in another worktree. [1]
Example of upstream shown in brackets:
* master 376438d [origin/master] … [2]
Also, -vv is where you’ll typically see gone in the brackets when a branch has an upstream configured but that upstream ref no longer exists locally (often after pruning). [3]
Sources:
[1] Git git-branch documentation (-v/-vv behavior) (git-scm.com)
[2] Example output showing upstream in brackets (git-memo.readthedocs.io)
[3] Explanation of gone in git branch -vv (stackoverflow.com)
Citations:
- 1: https://git-scm.com/docs/git-branch/2.38.0?utm_source=openai
- 2: https://git-memo.readthedocs.io/en/latest/remote_tracking.html?utm_source=openai
- 3: https://stackoverflow.com/questions/58651211/git-branch-not-showing-gone-for-missing-remotes?utm_source=openai
The regex truncates dotted branch names; git branch -v already shows tracking info.
Line 29's regex [^ \.]+ excludes dots, truncating branch names like release/1.0 to release/1. Change it to [^ ]+ to capture the full name.
Note: git branch -v already includes upstream tracking status (ahead/behind in brackets), so the ahead/behind regexes on Lines 30–31 should work as intended. Using -vv is optional and only adds the upstream branch name; it's not required for tracking info.
🤖 Prompt for AI Agents
In `@lib/git/status_shortcuts.rb` around lines 28 - 31, The branch-name regex is
incorrectly excluding dots and truncates names like release/1.0; in the git
parsing block that sets git_branch and `@branch` replace the pattern /^\*
(?:Initial commit on )?([^ \.]+)/ with one that allows dots (e.g. /^\*
(?:Initial commit on )?([^ ]+)/) so `@branch` captures the full branch name; keep
the existing ahead/behind captures (`@ahead` and `@behind`) as they already parse
the [ahead/behind] info from git branch -v.
| <img src="https://user-images.githubusercontent.com/139536/30827652-08e9b684-a265-11e7-95fb-50cbd2fb7c0d.png" width="200" height="200"> | ||
|
|
||
|
|
||
| ## /!\ this version contain a fix to works with windows! |
There was a problem hiding this comment.
Fix grammar and clarity in the Windows notice.
Line 3 is user-facing and currently ungrammatical; this can confuse readers. Consider a clearer sentence.
✏️ Suggested wording
-## /!\ this version contain a fix to works with windows!
+## Note: This version contains a fix to work with Windows (msysgit).📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## /!\ this version contain a fix to works with windows! | |
| ## Note: This version contains a fix to work with Windows (msysgit). |
🤖 Prompt for AI Agents
In `@README.markdown` at line 3, Update the user-facing heading string "## /!\
this version contain a fix to works with windows!" to a clear, grammatical
notice; replace it with a corrected sentence such as "## ⚠️ This version
contains a fix to work on Windows." — fix capitalization, verb agreement
("contains"), and wording ("to work on Windows") and keep the warning emphasis
(emoji or symbol) so readers immediately understand it's a Windows compatibility
fix.
Another fix for windows version
Summary by CodeRabbit
Bug Fixes
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.