Codecov Report

❌ Patch coverage is 74.83444% with 38 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.38%. Comparing base (876591a) to head (93cd768).
⚠️ Report is 9 commits behind head on main.

@@            Coverage Diff             @@
##             main      #17      +/-   ##
==========================================
+ Coverage   73.18%   73.38%   +0.20%     
==========================================
  Files          23       24       +1     
  Lines        1529     1676     +147     
==========================================
+ Hits         1119     1230     +111     
- Misses        331      357      +26     
- Partials       79       89      +10     

Code Review Summary

This is a well-implemented PR that adds a useful gw clean command for batch removing merged worktrees. The code follows the existing patterns, has comprehensive test coverage, and includes thoughtful error handling. Below are my detailed findings.

✅ Strengths

1. Excellent Code Quality

• Follows existing patterns from EndCommand consistently
• Well-structured with clear separation of concerns (checkWorktree, displayResults, removeWorktrees)
• Comprehensive test coverage (9 test cases covering all major scenarios)
• Good use of dependency injection for testability

2. User Experience

• Clear, concise output with visual indicators (✓, ✗, →)
• --dry-run flag for safe preview
• Confirmation prompt with count
• User-friendly error messages for broken worktrees

3. Safety First

• Performs the same three safety checks as gw end
• Only removes worktrees that pass ALL checks
• Respects auto_remove_branch configuration
• Graceful error handling with partial success reporting

4. Documentation

• Well-documented command with clear Long description
• CHANGELOG.md properly updated with comprehensive details
• Good inline comments explaining logic

🔍 Issues & Suggestions

High Priority

1. Missing constant for default base branch (cmd/command.go:621)

if wt.Branch == "" || wt.Branch == defaultBaseBranch || wt.Branch == "master" {

Issue: defaultBaseBranch is referenced but not defined in this file. This will cause a compilation error.

Fix: Either import/define the constant or use the string literal "main" directly (check how it's handled in other commands).

Medium Priority

2. Code duplication with EndCommand (cmd/command.go:676-733)

The checkWorktree method has significant overlap with EndCommand.performSafetyChecks():

• Both perform the same three safety checks
• Both handle errors similarly
• Both change directories and restore them

Suggestion: Extract common safety check logic into a shared function to reduce duplication and ensure consistency:

func performWorktreeSafetyChecks(deps *Dependencies) (hasChanges, hasUnpushed, isMerged bool, errors []error)

3. Inconsistent error message format (cmd/command.go:685, 702, 712, 722)

Some errors append full error details:

status.Warnings = append(status.Warnings, fmt.Sprintf("Could not access directory: %v", err))

While others use concise messages:

status.Warnings = append(status.Warnings, "uncommitted changes")

Suggestion: Consider making error messages consistently concise for the user-facing output, perhaps logging full errors to stderr instead.

4. Directory change side effects (cmd/command.go:684, 730)

The function changes the current working directory multiple times without proper error handling on restoration:

_ = os.Chdir(originalDir)

Suggestion: While the underscore shows intentional ignoring, consider at least logging if restoration fails, as this could affect subsequent operations.

Low Priority

5. Hard-coded "main" branch (cmd/command.go:720)

isMerged, err := c.deps.Git.IsMergedToOrigin("main")

Observation: This is consistent with EndCommand but hard-codes "main". Consider making the base branch configurable in future work (already noted in CLAUDE.md as a known limitation).

6. Test naming could be more specific (cmd/command_test.go:24)

const testBranch123 = "123/impl"

Suggestion: Consider testBranchPattern or testImplBranch to be more descriptive about its purpose.

7. Magic number in loop display (cmd/command.go:760)

if i > 0 {
    fmt.Fprintf(c.deps.Stdout, "\n")
}

Suggestion: Add a comment explaining why the blank line is added (to separate non-removable worktree entries for readability).

🛡️ Security Considerations

✅ No security issues found. The command:

• Uses the existing git interface abstractions
• Doesn't execute user-provided input directly
• Properly uses filepath operations
• Follows safe directory traversal patterns

🧪 Testing

Strengths:

• ✅ Comprehensive test coverage (9 test cases)
• ✅ Tests all major scenarios including edge cases
• ✅ Proper use of temporary directories
• ✅ Tests both success and failure paths
• ✅ Tests user interaction (confirmation, dry-run, force)

Suggestion:

Consider adding a test for the case where ListWorktrees() returns an error to ensure error handling at the entry point.

🏎️ Performance

✅ No performance concerns. The implementation:

• Efficiently iterates through worktrees once
• Uses pre-allocated slices with capacity hints
• Doesn't unnecessarily duplicate data structures
• Changes directories only when needed

📋 Minor Nits

1. Line 750: Consider extracting the emoji/symbol constants (✓, ✗, →) to package-level constants for consistency across commands.

2. Line 654-658: The singular/plural prompt logic is good, but could be extracted to a helper function if used elsewhere.

3. cmd/clean.go:13: The Long description could mention that it respects the auto_remove_branch configuration.

🎯 Final Recommendation

✅ APPROVE with minor fixes required

This is high-quality code that adds valuable functionality. The only blocking issue is the missing defaultBaseBranch constant reference that will prevent compilation. Once that's fixed, this is ready to merge.

Required before merge:

• Fix the defaultBaseBranch undefined reference

Recommended for follow-up:

• Extract common safety check logic to reduce duplication with EndCommand
• Consider making base branch configurable (can be a separate PR)

Code Coverage: 81.9% is excellent for this type of utility. The test coverage comprehensively validates the new functionality.

Great work on this feature! 🚀

🤖 Review generated with Claude Code

Code Review: Add gw clean command

Overall Assessment

This is a well-implemented feature with excellent test coverage and thoughtful UX improvements. The code follows existing patterns, has comprehensive safety checks, and is thoroughly tested. However, there are a few security concerns and minor improvements to consider.

✅ Strengths

1. Excellent Test Coverage

• 609 lines of test code for 257 lines of implementation (2.4:1 ratio)
• 9 comprehensive test cases covering all edge cases
• Tests use proper isolation with temporary directories
• Good use of dependency injection for testability

2. Strong Safety Model

• Three-tier safety checks (uncommitted changes, unpushed commits, merge status)
• Graceful error handling for broken worktrees
• Confirmation prompts with proper singular/plural handling
• --dry-run and --force flags for flexibility

3. Good UX Design

• Clear visual separation (✓ and ✗ symbols)
• Concise output with directory names instead of full paths
• Combined error messages for better readability
• Helpful user-friendly error messages

4. Code Quality

• Follows existing patterns from EndCommand
• Proper separation of concerns (check, display, remove)
• Good use of structured data (WorktreeStatus)
• Consistent error handling and reporting

🔴 Security Concerns

Critical: Command Injection Vulnerability

Location: internal/git/worktree.go:63,114,218,221,236

The code passes user-controlled input directly to exec.Command without validation:

// Line 63 - CreateWorktree
cmd = exec.Command("git", "worktree", "add", worktreeDir, "-b", branchName, baseBranch)

// Line 114 - RemoveWorktreeByPath  
cmd := exec.Command("git", "worktree", "remove", worktreePath)

// Line 236 - RunCommand (MOST DANGEROUS)
func RunCommand(command string) error {
    cmd := exec.Command("sh", "-c", command)  // Direct shell execution\!
    ...
}

Risk: While exec.Command with separate arguments is generally safe from shell injection, the inputs (branchName, worktreePath, etc.) should still be validated to prevent:

1. Path traversal attacks
2. Git command injection via special characters
3. Unexpected behavior from malformed input

Specific concerns:

• branchName is derived from user input without validation (beyond sanitization for directory names)
• worktreePath comes from git worktree list but could be manipulated
• RunCommand() at line 236 is extremely dangerous - it executes arbitrary shell commands

Recommendations:

1. Add input validation for branch names (alphanumeric, hyphens, slashes, underscores only)
2. Add path validation to ensure paths don't escape expected directories
3. Critical: Remove or severely restrict RunCommand() - if needed, use an allowlist of specific commands
4. Consider using filepath.Clean() on all path inputs
5. Add unit tests for malicious inputs

Example validation:

func validateBranchName(branch string) error {
    // Allow alphanumeric, hyphens, slashes, underscores
    matched, _ := regexp.MatchString("^[a-zA-Z0-9/_-]+$", branch)
    if \!matched {
        return fmt.Errorf("invalid branch name: %s", branch)
    }
    return nil
}

⚠️ Issues to Address

1. Directory Traversal Safety (cmd/command.go:684)

if err := os.Chdir(info.Path); err \!= nil {

Issue: The code changes to directories from git worktree list without validating they're within expected bounds.

Risk: If git metadata is corrupted or manipulated, this could lead to operations in unexpected locations.

Recommendation: Validate that paths are absolute and within repository boundaries.

2. Error Message Information Leakage (cmd/command.go:685,702,712,722)

status.Warnings = append(status.Warnings, fmt.Sprintf("Could not access directory: %v", err))
status.Warnings = append(status.Warnings, fmt.Sprintf("Could not check uncommitted changes: %v", err))

Issue: Full error messages (including system paths) are displayed to users.

Risk: Minor information disclosure in multi-user environments.

Recommendation: Use generic error messages or sanitize paths in error output.

3. Ignored Error in Directory Restoration (cmd/command.go:699,730)

_ = os.Chdir(originalDir)

Issue: If changing back to the original directory fails, the program continues in an unexpected location.

Risk: Subsequent operations may occur in wrong directory.

Recommendation: Log these errors at minimum, or propagate them:

if err := os.Chdir(originalDir); err \!= nil {
    // Log error or add to warnings
    status.Warnings = append(status.Warnings, "Failed to restore directory")
}

4. Config Load Error Silently Ignored (cmd/command.go:583)

cfg, _ := config.Load(config.GetConfigPath())

Issue: Configuration loading errors are ignored.

Impact: Users won't know if their config file is corrupted or has permission issues.

Recommendation: Log or display config loading errors.

5. Race Condition Window (cmd/command.go:625-672)

Issue: Time-of-check-time-of-use (TOCTOU) race condition between checking worktree status and removing it.

Scenario: User could push commits or modify worktree between the check and removal.

Risk: Low (single-user tool, short time window)

Recommendation: Document this limitation or add a re-check before removal.

💡 Suggestions for Improvement

1. Hardcoded Base Branch (cmd/command.go:621)

if wt.Branch == "" || wt.Branch == defaultBaseBranch || wt.Branch == "master" {

Suggestion: Use config to specify protected branches instead of hardcoding "main" and "master".

2. Duplicate Logic with EndCommand

Both EndCommand.performSafetyChecks() and CleanCommand.checkWorktree() perform similar checks.

Suggestion: Extract common safety check logic into a shared function to reduce duplication and ensure consistency.

3. Better Progress Feedback

For large numbers of worktrees, add progress indicators:

fmt.Fprintf(c.deps.Stdout, "Checking worktrees (%d/%d)...\r", current, total)

4. Atomic Operations

Consider wrapping multiple worktree removals in a transaction-like pattern where failures can be rolled back.

5. Output Buffering

For better performance when processing many worktrees, consider buffering output instead of multiple small writes.

📝 Minor Issues

1. Test Constant Duplication (cmd/command_test.go:19)

const testBranch123 = "123/impl"

Good addition, but consider defining more test constants for other repeated strings.

2. Inconsistent Spacing (cmd/command.go:761)

The blank line before displaying non-removable worktrees is inconsistent with the pattern used elsewhere.

3. Missing Documentation

The WorktreeStatus struct and its fields could benefit from doc comments explaining when CanRemove is false vs when Warnings are populated.

4. Magic Number (cmd/command.go:613)

statuses := make([]*WorktreeStatus, 0, len(worktrees))

Consider adding a comment explaining why capacity is set to len(worktrees) when some will be filtered out.

🧪 Test Coverage Comments

Great test coverage overall! Consider adding:

1. Test for concurrent modifications - What happens if a worktree changes during the check-remove window?
2. Test for permission errors - Simulate permission denied on directory access
3. Test for partial failure recovery - What happens if removal fails midway?
4. Test for very long paths - Ensure output formatting handles them gracefully
5. Benchmark tests - Performance with 100+ worktrees

📚 Documentation

The CHANGELOG entry is excellent and comprehensive. Consider also:

1. Updating README with examples of the new command
2. Adding a section about what makes a worktree "safely deletable"
3. Documenting the force and dry-run flags

✅ Pre-merge Checklist

• Tests pass
• CHANGELOG updated
• Follows conventional commits
• Code formatted (make fmt)
• Security issues addressed (command injection validation)
• Consider extracting shared safety check logic

Conclusion

This is a solid feature implementation with excellent testing and UX. The main concern is the command injection vulnerability that exists in the underlying git package. This should be addressed before merging, either in this PR or as a follow-up security PR.

Recommendation: Approve with minor changes - address the security concerns around input validation, then this is ready to merge.

Great work on the comprehensive tests and thoughtful UX improvements! 🎉

Review conducted by Claude Code following CLAUDE.md guidelines

Code Review for PR #17: Add gw clean command

Overall, this is a well-implemented and thoroughly tested feature that adds significant value to the tool. The code quality is high, follows existing patterns, and includes comprehensive test coverage.

✅ Strengths

1. Excellent Code Organization

• Clean separation of concerns with CleanCommand struct following the same pattern as EndCommand
• Well-structured methods: Execute(), checkWorktree(), displayResults(), and removeWorktrees()
• Consistent dependency injection pattern

2. Comprehensive Test Coverage

• 609 lines of tests covering 9 test scenarios
• Tests cover all edge cases: no worktrees, all removable, mixed, dry-run, force, user decline, errors, broken worktrees
• Maintains 81.9% code coverage
• Uses proper test isolation with t.TempDir() and mocking

3. User Experience

• Clear, informative output with visual separators
• Helpful confirmation prompts with proper pluralization
• --dry-run flag for safe previewing
• --force flag for automation
• Displays only directory names instead of full paths

4. Safety First

• Reuses the same three safety checks from gw end
• Graceful error handling for broken worktrees
• User-friendly error messages

5. Documentation

• Well-updated CHANGELOG.md
• Clear command help text

🔍 Issues & Concerns

Critical: Hardcoded Emoji Symbols 🚨

Lines: cmd/command.go:758, 767, 797, 802, 810, 820, 823

The code uses hardcoded emoji symbols instead of the symbol constants defined at lines 14-22. This creates inconsistency with the refactored init.go which properly uses the constants.

Impact:

• Inconsistent with the PRs own refactoring of init.go
• Makes future updates harder
• Violates DRY principle

Recommendation: Replace hardcoded emojis with symbol constants (symbolSuccess, symbolError, symbolWarning)

Security: Directory Traversal Risk ⚠️

Line: cmd/command.go:692

The code changes to arbitrary worktree directories without validating the path. Add path validation before os.Chdir().

Code Quality: Error Handling Inconsistency

Lines: cmd/command.go:692-695, 707, 738

Use defer for guaranteed directory restoration instead of ignoring errors with underscore.

Minor: Magic String main

Line: cmd/command.go:728

The branch name main is hardcoded in IsMergedToOrigin(). Consider using defaultBaseBranch constant or making it configurable.

📊 Test Coverage Analysis

The tests are exemplary. One gap: No test for the ListWorktrees() error case (line 616).

🔒 Security Assessment

Overall Risk Level: LOW ✅

🎯 Recommendations Summary

Must Fix:

1. Use symbol constants instead of hardcoded emojis

Should Fix:

2. Add defer for directory restoration
3. Validate paths before os.Chdir()

Nice to Have:

4. Add test for ListWorktrees() error case
5. Document or make configurable the hardcoded main branch
6. Add usage examples to help text

✅ Conclusion

This is excellent work! The feature is well-designed, thoroughly tested, and adds real value.

The only critical issue is the inconsistent use of hardcoded emojis instead of the symbol constants.

Once the emoji constants are fixed, this PR will be ready to merge.

Recommendation: Approve with minor changes ✅