Skip to content

fix(core): resolve --from ref to SHA to prevent git DWIM overriding branch name#147

Merged
helizaga merged 2 commits intocoderabbitai:mainfrom
damianlewis:fix/resolve-from-ref-to-sha
Mar 2, 2026
Merged

fix(core): resolve --from ref to SHA to prevent git DWIM overriding branch name#147
helizaga merged 2 commits intocoderabbitai:mainfrom
damianlewis:fix/resolve-from-ref-to-sha

Conversation

@damianlewis
Copy link
Contributor

@damianlewis damianlewis commented Feb 27, 2026

Summary

  • When --from <ref> matches a remote tracking branch name, git's guess-remote logic overrides the explicit -b flag and creates a tracking branch with the remote name instead of the requested name
  • Fix resolves from_ref to a commit SHA before passing it to git worktree add -b, preventing git from matching it to a remote branch
  • Uses git rev-parse --verify with an origin/ fallback, compatible with all supported git versions (2.17+)

Closes #146

Test plan

  • All 330 existing BATS tests pass (same 9 pre-existing failures unrelated to this change)
  • 7 new tests added covering all --from ref 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
    • --from with auto track mode — honours from_ref
    • --from <invalid-ref> — fails with error

Summary by CodeRabbit

  • Bug Fixes

    • Improve worktree creation so branch references are reliably resolved to the intended commit, avoiding accidental selection of remote branches when names overlap.
  • Tests

    • Expanded tests covering worktree creation from local branches, remote branches, tags, commit SHAs, auto mode behavior, and invalid-reference error handling.

…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.
@coderabbitai
Copy link

coderabbitai bot commented Feb 27, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent 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.

📥 Commits

Reviewing files that changed from the base of the PR and between 22d14d9 and e674c88.

📒 Files selected for processing (2)
  • lib/core.sh
  • tests/core_create_worktree.bats
🚧 Files skipped from review as they are similar to previous changes (2)
  • tests/core_create_worktree.bats
  • lib/core.sh

Walkthrough

Resolves from_ref to an unambiguous commit SHA (tries from_ref, then origin/from_ref, then falls back) and uses that resolved_ref when creating worktrees to avoid Git's guess-remote behavior that can override -b when from_ref matches a remote branch name.

Changes

Cohort / File(s) Summary
Core implementation
lib/core.sh
Add resolved_ref resolution using git rev-parse --verify (try from_ref, then origin/from_ref, else fallback). Replace usages of from_ref with resolved_ref in worktree creation paths for none and auto track modes to prevent guess-remote from overriding -b.
Test coverage
tests/core_create_worktree.bats
Add extensive tests for --from handling: local branch, lightweight tag, annotated tag, commit SHA, remote-tracking ref, auto mode behavior, and invalid from_ref error handling; assert correct starting commits and branch naming.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I sniffed the refs both near and far,
Resolved the SHA and set the branch ajar,
No guessing now where branches start,
A tidy worktree — straight from the heart! 🥕✨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main fix: resolving --from ref to SHA to prevent git DWIM from overriding the branch name.
Linked Issues check ✅ Passed The pull request fully addresses issue #146's objectives: resolves from_ref to commit SHA, prevents git DWIM override, ensures correct branch naming, maintains Git 2.17+ compatibility, and includes comprehensive tests.
Out of Scope Changes check ✅ Passed All changes are directly scoped to fixing the identified issue—modifying core.sh to resolve refs and adding tests for the new behavior with no extraneous modifications.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a 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

🤖 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.

📥 Commits

Reviewing files that changed from the base of the PR and between 0403d74 and 22d14d9.

📒 Files selected for processing (2)
  • lib/core.sh
  • tests/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.
@helizaga helizaga merged commit 4a4e21b into coderabbitai:main Mar 2, 2026
4 checks passed
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.

git worktree add -b ignores branch name when ref matches remote (guess-remote override)

2 participants