feat: multi-line display format for wt recent

[tobiase]

Summary

This PR changes the default display format for wt recent to a multi-line format that shows full branch names without truncation, which is much better for small terminal windows.

Changes

• Multi-line format is now the default - Each branch entry displays across 3 lines:

  • Line 1: Index, worktree indicator (*), and full branch name
  • Line 2: Commit subject (indented)
  • Line 3: Author and date (indented)
  • Blank line between entries for readability

• Added --compact/-c flag - Use this to get the previous single-line format

• No more truncation - Branch names are shown in full, solving the issue with long branch names

• Updated help documentation - Reflects the new default behavior

Why this change?

As mentioned in the discussion, when working with small terminal displays (like tmux panes), the truncated branch names were problematic. With naming schemes like <username>/<issue-id>/<description>, branch names get very long and important information was being cut off.

The multi-line format solves this by:

• Showing the full branch name
• Better visual separation between branches
• More readable layout for scanning through branches

Example Output

Default (multi-line):

0:* feat/multiline-recent-display
   feat: add performance benchmarks for wt recent command
   Tobias Englert, 2 hours ago

1:  fix/recent-error-handling-and-tests
   feat: add performance benchmarks for wt recent command
   Tobias Englert, 2 hours ago

With --compact flag:

0: *feat/multiline-recent-display       2 hours ago feat: add performance benchmarks for wt recent ... Tobias Englert
1:  fix/recent-error-handling-and-tests 2 hours ago feat: add performance benchmarks for wt recent ... Tobias Englert

Also included

• Closed task-24 (worktree caching) as won't implement, based on benchmark results showing the bottleneck is git operations, not our Go code

Test Plan

• Unit tests added for both display formats
• Manual testing with various branch name lengths
• Verified help documentation is accurate
• All existing tests pass

[claude]

Claude finished @tobiase's task —— View job

---

PR Review Complete

Review Checklist:

• Read and analyze main.go changes
• Review test coverage and quality in recent_test.go
• Check help.go modifications
• Evaluate Go best practices and code quality
• Check for potential bugs or issues
• Assess performance considerations
• Provide comprehensive feedback

---

Code Quality Assessment ⭐⭐⭐⭐⭐

This PR demonstrates excellent code quality with thoughtful implementation, comprehensive testing, and attention to detail. The changes are well-architected and follow Go best practices consistently.

Strengths

🏗️ Architecture & Design

• Clean separation of concerns: Multi-line (displayBranches) and compact (displayBranchesCompact) display functions are well-separated
• Backward compatibility: Existing functionality preserved with --compact flag
• Consistent flag parsing: New --compact/-c flag follows established patterns in parseRecentFlags()
• Smart defaults: Multi-line format addresses the real UX problem of truncated branch names

📝 Code Quality

• Excellent function naming: displayBranches() vs displayBranchesCompact() clearly indicates purpose
• Proper error handling: All error cases handled consistently with printErrorAndExit()
• Good performance: displayBranchesCompact() includes dynamic column width calculation that's both efficient and readable
• Unicode support: Proper handling of Unicode characters in truncateWithEllipsis() using []rune

🧪 Test Coverage

• Comprehensive test suite: 978 lines of tests covering multiple scenarios
• Edge case testing: Unicode, long branch names, empty inputs, performance with 1000+ branches
• Real-world scenarios: Tests actual branchCommitInfo structs, not just simple strings
• Performance testing: Includes benchmarks ensuring filtering remains fast with large datasets

📚 Documentation

• Updated help system: help.go properly documents the new --compact flag
• Clear examples: Help text shows both usage patterns effectively
• Consistent descriptions: Flag descriptions match the actual behavior

Technical Review

main.go:247-299 (handleRecentCommand)

The refactored handleRecentCommand function is well-structured:

• Flag parsing is clean and follows existing patterns
• Control flow is logical (navigation → display → summary)
• The conditional display logic (flags.compact) is simple and clear

main.go:1615-1647 (displayBranches)

The new multi-line display function is excellent:

• Clear formatting: Each branch uses exactly 3 lines with consistent indentation
• Worktree indicators: The * prefix clearly shows which branches have worktrees
• Proper spacing: Blank lines between entries improve readability
• Bounds checking: Proper handling of displayCount limits

main.go:1649-1720 (displayBranchesCompact)

The compact format shows sophisticated formatting:

• Dynamic column sizing: Calculates optimal widths based on actual content
• Reasonable limits: Maximum widths prevent overly wide displays
• Proper truncation: truncateWithEllipsis() handles Unicode correctly
• Alignment: Consistent column alignment across all rows

Minor Suggestions

1. Consider Terminal Width Detection (Enhancement)

The compact format uses fixed maximum widths. Consider detecting terminal width for better responsiveness:

// Could add terminal width detection for better adaptive display
termWidth := getTerminalWidth() // hypothetical function
maxBranchLen = min(maxBranchLen, termWidth/4)

2. Extract Magic Numbers (Code Quality)

In displayBranchesCompact(), consider extracting magic numbers as constants:

const (
    DefaultBranchWidth = 15
    DefaultDateWidth = 10
    DefaultSubjectWidth = 30
    MaxBranchWidth = 40
    MaxSubjectWidth = 50
    MaxDateWidth = 20
)

3. Consider Flag Validation (Robustness)

While not necessary for this change, parseRecentFlags() could validate flag combinations more explicitly:

// Already handled well, but could be more explicit
if flags.showOthers && flags.showAll {
    return recentFlags{}, fmt.Errorf("cannot use --others and --all together")
}

Performance Considerations

The implementation is performance-conscious:

• Efficient sorting: Uses sort.Slice with timestamp comparison
• Single-pass filtering: filterBranches() is O(n)
• Lazy evaluation: Display functions only process displayCount items
• Memory efficient: No unnecessary string concatenation in hot paths

Performance tests confirm filtering remains fast even with 1000+ branches.

Security Considerations

No security concerns identified. The code:

• Doesn't execute external commands in new code paths
• Handles user input (branch names) safely
• Uses proper string escaping for output
• Follows existing security patterns in the codebase

Verdict

This PR represents high-quality software development:

• ✅ Solves the real UX problem (truncated branch names)
• ✅ Maintains backward compatibility
• ✅ Includes comprehensive testing
• ✅ Follows established patterns and conventions
• ✅ Considers performance implications
• ✅ Provides clear documentation

The multi-line format effectively addresses the issue with long branch names in small terminal windows, while the --compact flag preserves the original behavior for users who prefer it.

Recommendation: ✅ APPROVE

This PR is ready for merge. The implementation is solid, well-tested, and provides clear value to users.

---