Enhance commit tracking and API performance

[popand]

Summary

• Added total lifetime commits display using GitHub Search API instead of misleading count (was showing 5)
• Increased API pagination from 30 to 100 commits per repository for more comprehensive data collection
• Enhanced commit data limits from 150 to 500 total commits across all repositories

Test plan

• Verify Total Commits tile now shows actual lifetime commits from GitHub
• Confirm All Commits view displays more complete commit history (up to 100 per repo)
• Test both authenticated and non-authenticated user flows
• Ensure GitHub API rate limits are respected with new pagination

🤖 Generated with Claude Code

[claude]

🔍 Pull Request Review

Thanks for this enhancement! I've thoroughly reviewed the changes and have some constructive feedback:

✅ Strengths

• Clear Problem Resolution: Successfully addresses the misleading commit count issue (was showing 5 instead of actual lifetime commits)
• Appropriate API Usage: Uses GitHub Search API (/search/commits) correctly for lifetime commit counting
• Performance Improvements: Increased pagination from 30→100 commits per repo and total limit from 150→500 commits
• Proper Error Handling: New fetchTotalCommitCount() method follows existing error handling patterns
• UI Integration: Clean integration into the Stats view with proper data binding
• Mock Data Consistency: Updated mock data includes the new totalLifetimeCommits field

🚨 Critical Issues

1. Rate Limiting Concerns ⚠️

The GitHub Search API has strict rate limits (30 requests/hour for authenticated users). This could cause the app to hit limits quickly, especially with increased pagination (30→100 per repo) and the new total commit count API call.

Recommendation: Implement caching or consider using GraphQL API for more efficient data fetching.

2. Missing Error Handling 🛑

The new fetchTotalCommitCount() call in loadData() (line 843) could fail independently of fetchContributionStats(), but there's no fallback for partial failures.

Recommendation: Add graceful degradation using optional try.

3. Test Coverage Gap 📋

No tests exist for the new fetchTotalCommitCount() functionality. The existing GitStreakDataModelTests.swift should be updated.

🚀 Performance & Security

• Network Efficiency: Changes increase data fetching but provide more comprehensive information
• Memory Usage: Increased commit limits (150→500) within reasonable bounds for mobile apps
• UI Responsiveness: Proper async/await usage maintained
• Security: ✅ No concerns - proper token validation and authentication patterns followed

🎯 Overall Assessment

This is a solid improvement that addresses the core issue effectively. The code follows existing patterns well and integrates cleanly. Main concerns are around rate limiting and error handling robustness.

Recommendation: ✅ Approve with minor modifications

Consider implementing the error handling improvements before merging to ensure a robust user experience.

[claude]

Code Review - PR #20: Enhance commit tracking and API performance

✅ Positive Changes

1. Better Total Commits Display - The change from dataModel.recentCommits.count to dataModel.totalLifetimeCommits in ContentView.swift:259 provides users with their actual lifetime commit count instead of just showing "5".

2. Improved Data Collection - Increasing per-page limit from 30 to 100 commits and total limit from 150 to 500 commits will provide more comprehensive data for users with high activity.

3. Clean UI Improvement - Removing the unused notification bell button (ContentView.swift:50-56) simplifies the interface.

4. Better Awards Layout - The visual improvements in AwardsTabView.swift improve the shadow and padding structure.

🔍 Areas for Improvement

Performance & API Concerns

• Rate Limiting Risk: The new fetchTotalCommitCount() method uses GitHub Search API which has stricter rate limits (30 requests/hour) compared to REST API (5000/hour). Consider adding rate limit handling and caching.
• API Call Efficiency: Adding another API call during data refresh could slow down the user experience. Consider batching this with existing calls or implementing smart caching.

Error Handling

• Missing Error Handling: In GitStreakData.swift:840-855, if fetchTotalCommitCount() fails, the error is caught but totalLifetimeCommits remains 0. Consider implementing graceful fallback or user notification.
• Network Resilience: The new API call doesn't implement retry logic like other GitHub API calls in the codebase.

Security Considerations ✅

• The implementation correctly uses the existing authentication token
• No security vulnerabilities introduced
• Maintains existing secure practices

🧪 Test Coverage Issues

• Missing Tests: No tests found for the new fetchTotalCommitCount() method
• Integration Testing: The new feature should be tested in GitHubServiceFunctionalTests.swift
• Mock Data: The mock data includes totalLifetimeCommits = 1247 but this should be tested to ensure UI consistency

💡 Recommendations

1. Add Rate Limit Handling:

// In fetchTotalCommitCount()
if httpResponse.statusCode == 403 {
    // Check if it's a rate limit error and handle gracefully
    throw GitHubError.rateLimitExceeded
}

2. Implement Caching:

// Cache total commits for 1 hour to reduce API calls
private var cachedTotalCommits: (count: Int, timestamp: Date)?

3. Add Error Recovery:

// In loadGitHubData(), provide fallback value
self.totalLifetimeCommits = totalCommits ?? self.recentCommits.count

4. Write Tests (GitStreakDataModelTests.swift):

func testFetchTotalCommitCount() async throws {
    // Test successful fetch
    // Test error handling
    // Test rate limit scenarios
}

📊 Code Quality Score: 7.5/10

Strengths: Good UX improvement, clean implementation, follows existing patterns
Needs Work: Error handling, test coverage, rate limit considerations

The changes provide genuine value to users but would benefit from more robust error handling and comprehensive testing before merging.