
windows-git-bash-paths
Windows and Git Bash path handling for SSDT, SqlPackage, and DACPAC files. PROACTIVELY activate for: (1) SqlPackage failing on Git Bash with path errors, (2) DACPAC file path conversion (MSYS, MINGW), (3) shell detection (PowerShell vs Git Bash) for SSDT scripts, (4) MSYSNOPATHCONV usage, (5) Windows-style backslash paths in publish profiles, (6) running dotnet build of .sqlproj from Git Bash, (7) cross-platform pipeline compatibility, (8) line-ending issues in SQL files. Provides: SqlPackage path-conversion recipes, shell-detection helpers, dotnet build patterns from bash, and CRLF/LF normalization steps.
- Installs
- 169
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/josiahsiegel/claude-plugin-marketplace --skill windows-git-bash-paths- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads windows-git-bash-paths automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
🚨 CRITICAL GUIDELINES
Windows File Path Requirements
MANDATORY: Always Use Backslashes on Windows for File Paths
When using Edit or Write tools on Windows, you MUST use backslashes (\) in file paths, NOT forward slashes (/).
Examples:
- ❌ WRONG:
D:/repos/project/file.tsx - ✅ CORRECT:
D:\repos\project\file.tsx
This applies to:
- Edit tool file_path parameter
- Write tool file_path parameter
- All file operations on Windows systems
Documentation Guidelines
NEVER create new documentation files unless explicitly requested by the user.
- Priority: Update existing README.md files rather than creating new documentation
- Repository cleanliness: Keep repository root clean - only README.md unless user requests otherwise
- Style: Documentation should be concise, direct, and professional - avoid AI-generated tone
- User preference: Only create additional .md files when user specifically asks for documentation
Windows and Git Bash Path Handling for SSDT
Overview
SQL Server development is Windows-heavy, and many developers use Git Bash (MINGW/MSYS2) as their preferred shell on Windows. This creates unique path conversion challenges when working with Windows-native tools like SqlPackage, MSBuild, and Visual Studio that expect Windows-style paths.
This skill provides comprehensive guidance on handling path conversion issues, shell detection, and best practices for SSDT workflows on Windows with Git Bash.
The Path Conversion Problem
What Happens in Git Bash/MINGW
Git Bash automatically converts POSIX-style paths to Windows paths, but this can cause issues with command-line arguments:
Automatic Conversions:
/foo→C:/Program Files/Git/usr/foo/foo:/bar→C:\msys64\foo;C:\msys64\bar--dir=/foo→--dir=C:/msys64/foo
Problematic for SqlPackage:
# Git Bash converts /Action to a path!
sqlpackage /Action:Publish /SourceFile:MyDB.dacpac
# Becomes: sqlpackage C:/Program Files/Git/usr/Action:Publish ...
What Triggers Conversion
✓ Leading forward slash (/) in arguments
✓ Colon-separated path lists
✓ Arguments after - or , with path components
What's Exempt
✓ Arguments containing = (variable assignments)
✓ Drive specifiers (C:)
✓ Arguments with ; (already Windows format)
✓ Arguments starting with // (Windows switches)
Solutions for SqlPackage in Git Bash
Method 1: MSYS_NO_PATHCONV (Recommended)
Disable path conversion for specific commands:
# Temporarily disable path conversion
MSYS_NO_PATHCONV=1 sqlpackage /Action:Publish \
/SourceFile:"MyDatabase.dacpac" \
/TargetServerName:"localhost" \
/TargetDatabaseName:"MyDB"
# Works for all SqlPackage actions
MSYS_NO_PATHCONV=1 sqlpackage /Action:Extract \
/SourceConnectionString:"Server=localhost;Database=MyDB;Integrated Security=True;" \
/TargetFile:"MyDB_backup.dacpac"
Important Notes:
- The VALUE doesn't matter - setting to
0,false, or empty still disables conversion - Only matters that variable is DEFINED
- To re-enable:
env -u MSYS_NO_PATHCONV
Method 2: Double Slash // (Alternative)
Use double slashes for SqlPackage parameters:
# Works in Git Bash and CMD
sqlpackage //Action:Publish \
//SourceFile:MyDatabase.dacpac \
//TargetServerName:localhost \
//TargetDatabaseName:MyDB
# Extract with double slashes
sqlpackage //Action:Extract \
//SourceConnectionString:"Server=localhost;Database=MyDB;Integrated Security=True;" \
//TargetFile:output.dacpac
Advantages:
- No environment variable needed
- Works across shells
- Shell-agnostic scripts
Method 3: Use Windows-Style Paths with Quotes
Always quote paths with backslashes:
# Quoted Windows paths work in Git Bash
MSYS_NO_PATHCONV=1 sqlpackage /Action:Publish \
/SourceFile:"D:\Projects\MyDB\bin\Release\MyDB.dacpac" \
/TargetConnectionString:"Server=localhost;Database=MyDB;Integrated Security=True;"
# Or with forward slashes (Windows accepts both)
MSYS_NO_PATHCONV=1 sqlpackage /Action:Publish \
/SourceFile:"D:/Projects/MyDB/bin/Release/MyDB.dacpac" \
/TargetConnectionString:"Server=localhost;Database=MyDB;Integrated Security=True;"
Method 4: Switch to PowerShell or CMD
For Windows-native tools, consider using native shells:
# PowerShell (recommended for Windows SSDT workflows)
sqlpackage /Action:Publish `
/SourceFile:"MyDatabase.dacpac" `
/TargetServerName:"localhost" `
/TargetDatabaseName:"MyDB"
:: CMD
sqlpackage /Action:Publish ^
/SourceFile:"MyDatabase.dacpac" ^
/TargetServerName:"localhost" ^
/TargetDatabaseName:"MyDB"
Shell Detection for Scripts
Bash Script Detection
#!/bin/bash
# Method 1: Check $OSTYPE
case "$OSTYPE" in
msys*) # MSYS/Git Bash/MinGW
export MSYS_NO_PATHCONV=1
SQLPACKAGE_ARGS="/Action:Publish /SourceFile:MyDB.dacpac"
;;
cygwin*) # Cygwin
export MSYS_NO_PATHCONV=1
SQLPACKAGE_ARGS="/Action:Publish /SourceFile:MyDB.dacpac"
;;
linux-gnu*) # Linux
SQLPACKAGE_ARGS="/Action:Publish /SourceFile:MyDB.dacpac"
;;
darwin*) # macOS
SQLPACKAGE_ARGS="/Action:Publish /SourceFile:MyDB.dacpac"
;;
esac
sqlpackage $SQLPACKAGE_ARGS
# Method 2: Check uname -s (most portable)
case "$(uname -s)" in
MINGW64*|MINGW32*)
# Git Bash
export MSYS_NO_PATHCONV=1
echo "Git Bash detected - path conversion disabled"
;;
MSYS_NT*)
# MSYS
export MSYS_NO_PATHCONV=1
echo "MSYS detected - path conversion disabled"
;;
CYGWIN*)
# Cygwin
export MSYS_NO_PATHCONV=1
echo "Cygwin detected - path conversion disabled"
;;
Linux*)
# Linux or WSL
echo "Linux detected"
;;
Darwin*)
# macOS
echo "macOS detected"
;;
esac
# Method 3: Check $MSYSTEM (Git Bash specific)
if [ -n "$MSYSTEM" ]; then
# Running in Git Bash/MSYS2
export MSYS_NO_PATHCONV=1
echo "MSYS environment detected: $MSYSTEM"
case "$MSYSTEM" in
MINGW64) echo "64-bit native Windows environment" ;;
MINGW32) echo "32-bit native Windows environment" ;;
MSYS) echo "POSIX-compliant environment" ;;
esac
fi
Complete Build Script Example
#!/bin/bash
# build-and-deploy.sh - Cross-platform SSDT build script
set -e # Exit on error
# Detect shell and set path conversion
if [ -n "$MSYSTEM" ]; then
echo "Git Bash/MSYS2 detected - disabling path conversion"
export MSYS_NO_PATHCONV=1
fi
# Variables
PROJECT_NAME="MyDatabase"
BUILD_CONFIG="Release"
DACPAC_PATH="bin/${BUILD_CONFIG}/${PROJECT_NAME}.dacpac"
TARGET_SERVER="${SQL_SERVER:-localhost}"
TARGET_DB="${SQL_DATABASE:-MyDB}"
# Build
echo "Building ${PROJECT_NAME}..."
dotnet build "${PROJECT_NAME}.sqlproj" -c "$BUILD_CONFIG"
# Verify DACPAC exists
if [ ! -f "$DACPAC_PATH" ]; then
echo "ERROR: DACPAC not found at $DACPAC_PATH"
exit 1
fi
echo "DACPAC built successfully: $DACPAC_PATH"
# Deploy
echo "Deploying to ${TARGET_SERVER}/${TARGET_DB}..."
# Use double-slash method for maximum compatibility
sqlpackage //Action:Publish \
//SourceFile:"$DACPAC_PATH" \
//TargetServerName:"$TARGET_SERVER" \
//TargetDatabaseName:"$TARGET_DB" \
//p:BlockOnPossibleDataLoss=False
echo "Deployment complete!"
Common SSDT Path Issues in Git Bash
Issue 1: DACPAC File Paths
Problem:
# Git Bash mangles the path
sqlpackage /Action:Publish /SourceFile:./bin/Release/MyDB.dacpac
# Error: Cannot find file
Solution:
# Use MSYS_NO_PATHCONV
MSYS_NO_PATHCONV=1 sqlpackage /Action:Publish \
/SourceFile:"./bin/Release/MyDB.dacpac"
# OR use absolute Windows path
MSYS_NO_PATHCONV=1 sqlpackage /Action:Publish \
/SourceFile:"D:/Projects/MyDB/bin/Release/MyDB.dacpac"
# OR use double slashes
sqlpackage //Action:Publish //SourceFile:./bin/Release/MyDB.dacpac
Issue 2: SQL Project File Paths
Problem:
# Path with spaces causes issues
dotnet build "D:/Program Files/MyProject/Database.sqlproj"
# Works in Git Bash (dotnet handles paths correctly)
# But MSBuild paths may fail
msbuild "D:/Program Files/MyProject/Database.sqlproj"
# May fail if not quoted properly
Solution:
# Always quote paths with spaces
dotnet build "D:/Program Files/MyProject/Database.sqlproj"
# Use backslashes for MSBuild on Windows
msbuild "D:\Program Files\MyProject\Database.sqlproj"
# Or use 8.3 short names (no spaces)
msbuild "D:/PROGRA~1/MyProject/Database.sqlproj"
Issue 3: Publish Profile Paths
Problem:
# Publish profile not found
sqlpackage /Action:Publish \
/SourceFile:MyDB.dacpac \
/Profile:./Profiles/Production.publish.xml
Solution:
# Use MSYS_NO_PATHCONV with quoted paths
MSYS_NO_PATHCONV=1 sqlpackage /Action:Publish \
/SourceFile:"MyDB.dacpac" \
/Profile:"./Profiles/Production.publish.xml"
# Or absolute Windows path
MSYS_NO_PATHCONV=1 sqlpackage /Action:Publish \
/SourceFile:"D:/Projects/MyDB.dacpac" \
/Profile:"D:/Projects/Profiles/Production.publish.xml"
Issue 4: Connection Strings
Problem:
# File paths in connection strings
/SourceConnectionString:"Server=localhost;Database=MyDB;Integrated Security=True;AttachDbFilename=D:/Data/MyDB.mdf"
# Path gets mangled
Solution:
# Quote entire connection string
MSYS_NO_PATHCONV=1 sqlpackage /Action:Extract \
/SourceConnectionString:"Server=localhost;Database=MyDB;Integrated Security=True;AttachDbFilename=D:\Data\MyDB.mdf" \
/TargetFile:"output.dacpac"
# Or use double backslashes in connection string
/SourceConnectionString:"Server=localhost;Database=MyDB;Integrated Security=True;AttachDbFilename=D:\\Data\\MyDB.mdf"
CI/CD Considerations
GitHub Actions with Git Bash
name: SSDT Build and Deploy
on: [push]
jobs:
build:
runs-on: windows-latest
defaults:
run:
shell: bash # Use Git Bash
steps:
- uses: actions/checkout@v4
- name: Setup .NET
uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.0.x'
- name: Install SqlPackage
run: dotnet tool install -g Microsoft.SqlPackage
- name: Build Database Project
run: dotnet build Database.sqlproj -c Release
- name: Deploy with Path Conversion Disabled
env:
MSYS_NO_PATHCONV: 1
run: |
sqlpackage /Action:Publish \
/SourceFile:"bin/Release/MyDatabase.dacpac" \
/TargetServerName:"localhost" \
/TargetDatabaseName:"MyDB"
PowerShell Alternative (Recommended for Windows)
jobs:
build:
runs-on: windows-latest
defaults:
run:
shell: pwsh # Use PowerShell - no path issues
steps:
- name: Deploy Database
run: |
sqlpackage /Action:Publish `
/SourceFile:"bin/Release/MyDatabase.dacpac" `
/TargetServerName:"localhost" `
/TargetDatabaseName:"MyDB"
Best Practices Summary
For Interactive Development
- Use PowerShell or CMD for SSDT on Windows - avoids path conversion issues entirely
- If using Git Bash, set
MSYS_NO_PATHCONV=1in your shell profile for SSDT work - Always quote paths containing spaces or special characters
- Use absolute paths when possible to avoid ambiguity
For Scripts
- Detect shell environment and set
MSYS_NO_PATHCONV=1conditionally - Use double-slash // syntax for SqlPackage arguments (most portable)
- Prefer PowerShell for Windows-specific workflows (build scripts, CI/CD)
- Test scripts on all target platforms (Windows PowerShell, Git Bash, Linux)
For CI/CD
- Use PowerShell shell in GitHub Actions for Windows runners (
shell: pwsh) - Self-hosted Windows agents - use native Windows paths and shells
- Set MSYS_NO_PATHCONV=1 as environment variable if Git Bash required
- Prefer dotnet CLI over MSBuild for cross-platform compatibility
For Teams
- Document shell requirements in repository README
- Provide scripts for all shells (bash, PowerShell, CMD)
- Standardize on PowerShell for Windows SSDT workflows when possible
- Use containerized builds to avoid shell-specific issues
Quick Reference
Environment Variables
# Disable path conversion (Git Bash/MSYS2/Cygwin)
export MSYS_NO_PATHCONV=1
# Re-enable path conversion
env -u MSYS_NO_PATHCONV
SqlPackage Command Templates
# Git Bash - Method 1 (MSYS_NO_PATHCONV)
MSYS_NO_PATHCONV=1 sqlpackage /Action:Publish /SourceFile:"MyDB.dacpac" /TargetServerName:"localhost" /TargetDatabaseName:"MyDB"
# Git Bash - Method 2 (Double Slash)
sqlpackage //Action:Publish //SourceFile:MyDB.dacpac //TargetServerName:localhost //TargetDatabaseName:MyDB
# PowerShell (Recommended for Windows)
sqlpackage /Action:Publish /SourceFile:"MyDB.dacpac" /TargetServerName:"localhost" /TargetDatabaseName:"MyDB"
# CMD
sqlpackage /Action:Publish /SourceFile:"MyDB.dacpac" /TargetServerName:"localhost" /TargetDatabaseName:"MyDB"
Shell Detection One-Liners
# Check if Git Bash/MSYS
[ -n "$MSYSTEM" ] && echo "Git Bash/MSYS2 detected"
# Check uname
[[ "$(uname -s)" =~ ^MINGW ]] && echo "Git Bash detected"
# Set path conversion conditionally
[ -n "$MSYSTEM" ] && export MSYS_NO_PATHCONV=1
Resources
- Git Bash Path Conversion Guide
- MSYS2 Path Conversion Documentation
- SqlPackage Documentation
- Microsoft.Build.Sql SDK
- Git for Windows
Troubleshooting
"Invalid parameter" errors
Symptom: SqlPackage reports "Invalid parameter" or "Unknown action"
Cause: Git Bash converting /Action to a file path
Fix: Use MSYS_NO_PATHCONV=1 or double-slash //Action
"File not found" with valid paths
Symptom: DACPAC or project file not found despite correct path
Cause: Path conversion mangling the file path
Fix: Quote paths and use MSYS_NO_PATHCONV=1
Build succeeds but publish fails
Symptom: dotnet build works but sqlpackage fails
Cause: dotnet CLI handles paths correctly, but SqlPackage uses / parameters
Fix: Use MSYS_NO_PATHCONV=1 for SqlPackage commands only
Spaces in paths cause errors
Symptom: Paths with "Program Files" or other spaces fail
Cause: Unquoted paths split into multiple arguments
Fix: Always quote paths: /SourceFile:"D:/Program Files/MyDB.dacpac"
FAQ
What does the windows-git-bash-paths skill do?
Windows and Git Bash path handling for SSDT, SqlPackage, and DACPAC files. PROACTIVELY activate for: (1) SqlPackage failing on Git Bash with path errors, (2) DACPAC file path conversion (MSYS, MINGW), (3) shell detection (PowerShell vs Git Bash) for SSDT scripts, (4) MSYSNOPATHCONV usage, (5) Windows-style backslash paths in publish profiles, (6) running dotnet build of .sqlproj from Git Bash, (7) cross-platform pipeline compatibility, (8) line-ending issues in SQL files. Provides: SqlPackage path-conversion recipes, shell-detection helpers, dotnet build patterns from bash, and CRLF/LF normalization steps.
How do I install windows-git-bash-paths?
Run npx skills add https://github.com/josiahsiegel/claude-plugin-marketplace --skill windows-git-bash-paths in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/windows-git-bash-paths/ (personal) or .claude/skills/windows-git-bash-paths/ (project).
Which AI agents can use windows-git-bash-paths?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is windows-git-bash-paths safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains windows-git-bash-paths?
It is published by josiahsiegel in josiahsiegel/claude-plugin-marketplace. It has 169 recorded installs.
More from josiahsiegel/claude-plugin-marketplace
tailwindcss-advanced-layouts
josiahsiegel/claude-plugin-marketplace
Tailwind CSS advanced layout techniques including CSS Grid and Flexbox patterns. PROACTIVELY activate for: (1) building complex layouts with CSS Grid, (2) grid-template-areas via Tailwind v4 arbitrary values, (3) responsive grid (grid-cols-, auto-fit, minmax), (4) Flexbox patterns (flex-1, flex-grow, gap), (5) sticky headers and footers, (6) holy grail layout, (7) masonry-style layouts, (8) container queries (@container) with Tailwind, (9) subgrid usage, (10) aspect-ratio utilities, (11) magazine-style multi-column layouts. Provides: Grid template recipes, container-query patterns, holy-grail templates, masonry alternatives, and aspect-ratio examples.
tailwindcss-animations
josiahsiegel/claude-plugin-marketplace
Tailwind CSS animations and transitions including built-in utilities and custom keyframes. PROACTIVELY activate for: (1) animate- utilities (spin, ping, pulse, bounce), (2) custom @keyframes via @theme animate, (3) transition utilities (transition, duration, ease), (4) transforms (scale, rotate, translate) with transition, (5) prefers-reduced-motion: reduce, (6) Framer Motion / Motion One integration with Tailwind, (7) CSS scroll-driven animations (animation-timeline), (8) view transitions API with Tailwind, (9) hover, focus, group-hover transitions, (10) staggered list animations. Provides: animation utility reference, custom keyframe examples, reduced-motion pattern, Framer Motion integration, and scroll-driven animation recipes.
tailwindcss-mobile-first
josiahsiegel/claude-plugin-marketplace
Mobile-first responsive design patterns with Tailwind CSS v4 (2025-2026). PROACTIVELY activate for: (1) mobile-first design with Tailwind breakpoints (sm:, md:, lg:, xl:, 2xl:), (2) responsive utility ordering (default = mobile, then breakpoints), (3) responsive typography (text-base sm:text-lg lg:text-xl), (4) responsive grids and flexbox, (5) hide/show across breakpoints (hidden md:block), (6) max- breakpoints for desktop-down overrides, (7) container queries (@container) for component-level responsiveness, (8) safe-area insets and notch handling, (9) landscape vs portrait orientation, (10) touch vs hover (hover: with @media). Provides: breakpoint reference, mobile-first patterns, container-query examples, safe-area recipes, and touch/hover handling.
powershell-master
josiahsiegel/claude-plugin-marketplace
Complete PowerShell expertise system across ALL platforms (Windows/Linux/macOS). PROACTIVELY activate for: (1) ANY PowerShell task (scripts/modules/cmdlets), (2) CI/CD automation (GitHub Actions/Azure DevOps/Bitbucket), (3) Cross-platform scripting, (4) Module discovery and management (PSGallery), (5) Azure/AWS/Microsoft 365 automation, (6) Script debugging and optimization, (7) Best practices and security. Provides: PowerShell 7+ features, popular module expertise (Az, Microsoft.Graph, PnP, AWS Tools), PSGallery integration, platform-specific guidance, CI/CD pipeline patterns, cmdlet syntax mastery, and production-ready scripting patterns. Ensures professional-grade, cross-platform PowerShell automation following industry standards.
docker-best-practices
josiahsiegel/claude-plugin-marketplace
Comprehensive Docker best practices for images, containers, and production deployments. PROACTIVELY activate for: (1) writing production-ready Dockerfiles, (2) multi-stage builds for lean images, (3) base image selection (distroless, alpine, scratch, slim), (4) layer caching and ordering, (5) .dockerignore hygiene, (6) HEALTHCHECK and graceful shutdown, (7) non-root user and least-privilege patterns, (8) ENV vs ARG and secret handling, (9) tag/digest pinning and reproducibility, (10) Compose for local development. Provides: Dockerfile templates by language, image-size optimization checklist, .dockerignore template, HEALTHCHECK patterns, and Compose dev-stack examples.
git-master
josiahsiegel/claude-plugin-marketplace
Complete Git expertise system for ALL git operations. PROACTIVELY activate for: (1) ANY Git task (basic/advanced/dangerous), (2) Repository management, (3) Branch strategies and workflows, (4) Conflict resolution, (5) History rewriting/recovery, (6) Platform-specific operations (GitHub/Azure DevOps/Bitbucket), (7) Advanced commands (rebase/cherry-pick/filter-repo). Provides: complete Git command reference, safety guardrails for destructive operations, platform best practices, workflow strategies, reflog recovery techniques, and expert guidance for even the most risky operations. Always asks user preference for automatic commits vs manual control.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.