fix(core): resolve --from ref to SHA to prevent git DWIM overriding branch name#147
Conversation
…ranch name When from_ref matches a remote branch name, git's guess-remote logic overrides the -b flag and creates a tracking branch with the remote name instead of the requested name. Resolving from_ref to a commit SHA before passing it to git worktree add prevents this.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
WalkthroughResolves Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@lib/core.sh`:
- Around line 452-454: The current git rev-parse calls that set resolved_ref
from from_ref can return tag objects for annotated tags; change the rev-parse
invocations to peel to the commit by appending ^{commit} (e.g. git rev-parse
--verify "$from_ref^{commit}" 2>/dev/null and git rev-parse --verify
"origin/$from_ref^{commit}" 2>/dev/null) so resolved_ref is always a commit SHA,
and make the same change where from_ref is resolved/validated prior to git
worktree add (the other rev-parse usages around the git worktree add -b calls)
so worktree add receives a commit-ish not a tag object.
In `@tests/core_create_worktree.bats`:
- Around line 162-177: Add a new test variant that creates an annotated tag
(e.g., with git tag -a ... -m ...) and then calls the existing test flow that
uses create_worktree to ensure the worktree starts at the peeled commit ID;
specifically, duplicate the "create_worktree from tag starts at the tagged
commit" test but replace the lightweight tag creation (git tag v1.0.0) with an
annotated tag creation, verify expected_sha is the commit before creating the
annotated tag, call create_worktree the same way, and assert the worktree's HEAD
equals that commit so create_worktree (and the git rev-parse usage in
lib/core.sh) handles tag objects correctly.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled
- Linear integration is disabled
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
lib/core.shtests/core_create_worktree.bats
Use ^{commit} peeling syntax in rev-parse to ensure resolved_ref is
always a commit SHA, not a tag object. Add annotated tag test case
alongside the existing lightweight tag test.
Summary
--from <ref>matches a remote tracking branch name, git's guess-remote logic overrides the explicit-bflag and creates a tracking branch with the remote name instead of the requested namefrom_refto a commit SHA before passing it togit worktree add -b, preventing git from matching it to a remote branchgit rev-parse --verifywith anorigin/fallback, compatible with all supported git versions (2.17+)Closes #146
Test plan
--fromref types:--from <local-branch>— resolves to correct commit--from <tag>— resolves to tagged commit--from <commit-sha>— passes through correctly--from <remote-branch-name>— uses requested branch name, not remote name (the bug)--from <remote-branch-name>— starts at correct commit--fromwith auto track mode — honours from_ref--from <invalid-ref>— fails with errorSummary by CodeRabbit
Bug Fixes
Tests