Skip to content

fix(git-ext): honor explicit -Number 0 in PowerShell branch creation (parity with bash)#3412

Open
Noor-ul-ain001 wants to merge 1 commit into
github:mainfrom
Noor-ul-ain001:fix/git-ext-number-zero-parity
Open

fix(git-ext): honor explicit -Number 0 in PowerShell branch creation (parity with bash)#3412
Noor-ul-ain001 wants to merge 1 commit into
github:mainfrom
Noor-ul-ain001:fix/git-ext-number-zero-parity

Conversation

@Noor-ul-ain001

Copy link
Copy Markdown
Contributor

Summary

The git extension's PowerShell branch-creation script silently ignored an explicit -Number 0. Because -Number is declared with a default of 0, the guards if ($Timestamp -and $Number -ne 0) and if ($Number -eq 0) could not tell an unset flag apart from a user passing -Number 0. A user asking for branch 000-... was routed into auto-detection and got the next sequential number instead.

This mirrors the same fix already landed for the core script in #3196 (scripts/powershell/create-new-feature.ps1) — the git-extension twin (extensions/git/scripts/powershell/create-new-feature-branch.ps1) still carried the bug.

Changes

  • Replace both -eq 0 / -ne 0 checks with $PSBoundParameters.ContainsKey('Number'), which tests whether the flag was actually supplied — mirroring the bash twin's empty-string sentinel (BRANCH_NUMBER="", [ -z "$BRANCH_NUMBER" ] / [ -n "$BRANCH_NUMBER" ]).
  • Add a parity regression test to both TestCreateFeatureBash and TestCreateFeaturePowerShell asserting --number 0 / -Number 0 yields 000-zero / FEATURE_NUM=000.
# Before: -Number 0 auto-detected the next number (e.g. 003-zero)
# After:  -Number 0 is honored → 000-zero
./create-new-feature-branch.ps1 -DryRun -Number 0 -ShortName zero "Zero feature"

Testing

Verified both twins manually (pwsh Core / real Git-for-Windows bash are gated by HAS_PWSH / requires_bash in CI):

Case Bash PowerShell
-Number 0 000-zero 000-zero
-Number 5 005-five
auto-detect (existing 001 spec) 001-auto 001-auto (parity)

🤖 Generated with Claude Code

`-Number` defaults to 0, so the previous `-eq 0` / `-ne 0` checks could
not distinguish an unset flag from an explicit `-Number 0`: a user
requesting branch `000-...` was silently routed into auto-detection.
Switch both checks to `$PSBoundParameters.ContainsKey('Number')`, which
tests whether the flag was actually supplied — mirroring the bash twin's
empty-string sentinel (`[ -z "$BRANCH_NUMBER" ]` / `[ -n ... ]`).

Add a parity regression test to both TestCreateFeatureBash and
TestCreateFeaturePowerShell asserting `--number 0` / `-Number 0` yields
`000-zero`.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a long-standing PowerShell parameter-binding ambiguity in the git extension’s branch-creation script so that an explicitly supplied -Number 0 is honored (producing 000-...) instead of being misinterpreted as “unset” and triggering auto-detection—bringing PowerShell behavior into parity with the bash twin.

Changes:

  • Update create-new-feature-branch.ps1 to use $PSBoundParameters.ContainsKey('Number') to distinguish “flag not provided” from “provided as 0”.
  • Add regression tests for both bash and PowerShell paths to pin the number=0FEATURE_NUM=000 / BRANCH_NAME=000-... behavior.
Show a summary per file
File Description
tests/extensions/git/test_git_extension.py Adds bash + PowerShell regression tests asserting explicit number=0 yields 000-* rather than auto-detecting the next number.
extensions/git/scripts/powershell/create-new-feature-branch.ps1 Switches “unset vs 0” detection from numeric comparisons to PSBoundParameters.ContainsKey('Number') for correct parity with bash.

Review details

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

  • Files reviewed: 2/2 changed files
  • Comments generated: 0
  • Review effort level: Low

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.

3 participants