| name | git-2025-features |
| description | Git 2.49+ features including reftables, sparse-checkout, partial clone, git-backfill, and worktrees |
📌 NOTE: For detailed Git 2.49+ features (git-backfill, path-walk API, zlib-ng), see git-2-49-features.md skill.
🚨 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
Git 2025 Features - Advanced Capabilities
Git 2.49 (March 2025) - Latest
Major additions: git-backfill, path-walk API, zlib-ng performance, improved delta compression.
See git-2-49-features.md for complete coverage.
Git 2.48-2.49 Features
Reftables Migration (Completed in 2.48)
What: New reference storage format replacing loose ref files and packed-refs.
Benefits:
- Faster ref operations (50-80% improvement)
- Atomic ref updates
- Better scalability for repositories with many refs
- Reflogs fully migratable (completed in 2.48)
Migration:
git config core.refStorage
git refs migrate --ref-storage=reftables
git fsck --full
git log --oneline -5
git refs migrate --ref-storage=files
When to use:
- Repositories with 10,000+ refs
- High-frequency branch operations
- CI/CD systems creating many temporary refs
- Monorepos with extensive branching
Performance Milestones (2.48-2.49)
Git 2.48:
- Memory leak free status achieved
- Stable memory usage in long-running operations
Git 2.49:
- zlib-ng integration: 20-30% faster compression
- Path-walk API: 50-70% better delta compression
- New name-hashing algorithm for optimal packfiles
Benefits automatically in:
- Large repository clones
- Extended rebase sessions
- Bulk operations (filter-repo, GC, repack)
Sparse-Checkout (Enhanced in 2.48)
What: Check out only a subset of files from repository.
Use cases:
- Monorepos (work on one service)
- Large repositories (reduce disk usage)
- Build systems (fetch only needed files)
Cone Mode (Default - Recommended):
git clone --filter=blob:none --sparse <repo-url>
cd <repo>
git sparse-checkout init --cone
git sparse-checkout set src/api src/shared docs
git sparse-checkout add tests/integration
git sparse-checkout list
git sparse-checkout check-rules src/api/users.ts
git sparse-checkout disable
Advanced Patterns (Non-Cone Mode):
git sparse-checkout init --no-cone
git sparse-checkout set \
"*.md" \
"src/api/*" \
"!src/api/legacy/*"
git sparse-checkout set --stdin < patterns.txt
Reapply Rules:
git sparse-checkout reapply
Partial Clone
What: Clone repository without downloading all objects initially.
Filters:
- blob:none - Defer all blobs (fastest, smallest)
- tree:0 - Defer all trees and blobs
- blob:limit=1m - Defer blobs larger than 1MB
Usage:
git clone --filter=blob:none <repo-url>
git clone --filter=blob:limit=10m <repo-url>
git clone --filter=blob:none --sparse <repo-url>
cd <repo>
git sparse-checkout set src/api
git config extensions.partialClone origin
git config remote.origin.promisor true
git fetch --filter=blob:none
git fetch --unshallow
Combine Partial Clone + Sparse-Checkout:
git clone --filter=blob:none --sparse <repo-url>
cd <repo>
git sparse-checkout set --cone src/api
git checkout main
Check promisor objects:
git config extensions.partialClone
ls -lah .git/objects/pack/*.promisor
git rev-list --objects --missing=print HEAD | grep "^?"
Git Worktrees
What: Multiple working directories from one repository.
Benefits:
- Work on multiple branches simultaneously
- No need to stash/commit before switching
- Parallel work (review PR while coding)
- Shared .git (one fetch updates all)
Basic Operations:
git worktree list
git worktree add ../project-feature feature-branch
git worktree add -b new-feature ../project-new-feature
git worktree add ../project-fix origin/fix-bug
git worktree remove ../project-feature
git worktree prune
Advanced Patterns:
git worktree add ../myproject-pr-123 origin/pull/123/head
cd ../myproject-pr-123
cd -
git worktree add --detach ../myproject-hotfix v1.2.3
cd ../myproject-hotfix
git switch -c hotfix/security-patch
git commit -am "fix: patch vulnerability"
git push -u origin hotfix/security-patch
mkdir -p ~/worktrees/myproject
git worktree add ~/worktrees/myproject/feature-a -b feature-a
git worktree add ~/worktrees/myproject/feature-b -b feature-b
git worktree add ~/worktrees/myproject/pr-review origin/pull/42/head
Best Practices:
- Organize directory structure:
~/projects/
myproject/
myproject-feature/
myproject-review/
- Clean up regularly:
git worktree list | grep feature | while read wt branch commit; do
if git branch --merged | grep -q "$branch"; then
git worktree remove "$wt"
fi
done
- Shared configuration:
- .git/config applies to all worktrees
- .git/info/exclude applies to all worktrees
- Each worktree has own index and HEAD
Scalar (Large Repository Tool)
What: Tool for optimizing very large repositories (Microsoft-developed).
scalar register <path>
scalar clone --branch main <repo-url>
scalar unregister <path>
scalar delete <path>
Git Backfill (Experimental)
What: Background process to fetch missing objects in partial clone.
git backfill
git backfill --min-batch-size=1000
git backfill --sparse
Performance Comparison
Traditional Clone:
git clone large-repo
Sparse-Checkout:
git clone --sparse large-repo
git sparse-checkout set src/api
Partial Clone:
git clone --filter=blob:none large-repo
Partial Clone + Sparse-Checkout:
git clone --filter=blob:none --sparse large-repo
git sparse-checkout set src/api
When to Use Each Feature
Sparse-Checkout:
- ✓ Monorepos
- ✓ Working on specific services/modules
- ✓ Limited disk space
- ✗ Need entire codebase often
Partial Clone:
- ✓ CI/CD pipelines
- ✓ Large repositories
- ✓ Good network connectivity
- ✗ Offline work frequently
Worktrees:
- ✓ Parallel development
- ✓ PR reviews during work
- ✓ Multiple branch testing
- ✗ Low disk space
Combine All:
- ✓ Massive monorepos (Google scale)
- ✓ Multiple simultaneous tasks
- ✓ Minimal local storage
- ✓ Fast network connection
Troubleshooting
Sparse-checkout not working:
git config core.sparseCheckout
git config core.sparseCheckoutCone
git sparse-checkout reapply
git sparse-checkout list
Missing objects in partial clone:
git fetch origin <commit>
git fetch --unshallow
git config extensions.partialClone
Worktree issues:
git worktree unlock <path>
git worktree remove --force <path>
git worktree prune
git checkout --ignore-other-worktrees <branch>
Migration Guide
From traditional to optimized workflow:
cd large-project
du -sh .git
cd ..
git clone --filter=blob:none --sparse large-project-new
cd large-project-new
git sparse-checkout set src/api src/shared
du -sh .git
cd ../large-project-new
rm -rf ../large-project
Resources