feat: add dirty file count display to Git segment

[ekain-fr]

Summary

Enhances the Git segment to display the count of dirty files (modified, staged, untracked) next to the status indicator, providing immediate visibility into repository state without running git commands.

Visual Examples:

• Clean: 🌿 master ✓
• Dirty without count: 🌿 feat/branch ●
• Dirty with count: 🌿 feat/branch ● 11 ← NEW
• With SHA: 🌿 feat/branch ● 11 a1b2c3d (both options enabled)

Changes

Core Git Segment (src/core/segments/git.rs)

• Add dirty_count: u32 field to GitInfo struct
• Modify get_status() to return (GitStatus, u32) tuple
  • Parses git status --porcelain output
  • Counts non-empty lines (1 line = 1 file)
• Update display logic in collect() method:
  • Format: ● 5 (dirty), ⚠ 3 (conflicts), ✓ (clean)
• Add with_dirty_count() builder method for configuration
• Store dirty_count in metadata for future use

Statusline Integration (src/core/statusline.rs)

• Read show_dirty_count option from segment configuration
• Pass option to GitSegment via builder pattern

Theme Configuration (9 files: src/ui/themes/theme_*.rs)

• Add show_dirty_count: true to all themes by default
• Consistent configuration across all theme presets:
  • Cometix, Default, Gruvbox, Minimal, Nord
  • Powerline Dark, Powerline Light, Powerline Rose Pine, Powerline Tokyo Night

TUI Configurator Integration

src/ui/components/segment_list.rs:

• Add ShowSha and ShowDirtyCount to FieldSelection enum

src/ui/components/settings.rs:

• Display Git-specific options in Settings panel
• Show checkbox toggles for both options

src/ui/app.rs:

• Add GIT_SEGMENT_FIELD_COUNT constant (9 fields)
• Implement field navigation for Git segment options
• Add toggle handlers for show_sha and show_dirty_count
• Update field index mapping

src/ui/components/preview.rs:

• Update mock data to respect Git segment options
• Dynamically build secondary status based on configuration
• Preview now shows real-time updates when toggling options

Configuration

Users can control this feature via config:

[segments.options]
show_sha = false            # Existing option
show_dirty_count = true     # New option (default: enabled)

TUI Navigation

1. Open configurator: ccline --config
2. Navigate to Git segment (↑/↓)
3. Switch to Settings panel (Tab)
4. Select "Show Dirty Count" (↑/↓)
5. Toggle with Enter
6. Preview updates in real-time

Default Behavior

Enabled by default in all themes:

• Provides valuable repository state information
• Minimal visual clutter (just a number)
• Easy to disable if not desired

Testing

• ✅ Compiles successfully: cargo build --release
• ✅ Tests pass: cargo test
• ✅ Accuracy verified: Matches git status --porcelain | wc -l
• ✅ TUI configurator: Options visible and toggle correctly
• ✅ Preview updates: Real-time feedback when toggling
• ✅ All 9 themes updated consistently

Tested scenarios:

• Clean repository (0 files): Shows ✓
• Dirty files: Shows ● 11 (11 files)
• With conflicts: Shows ⚠ 3 (3 conflicted files)
• Option disabled: Shows ● (backward compatible)
• Option enabled: Shows ● 5 (with count)

Implementation Details

Performance: Uses existing git status --porcelain call, just adds line counting
Compatibility: Non-breaking change, maintains backward compatibility
Configuration: Follows existing pattern (show_sha for Git segment)

Files Changed

15 files changed, 198 insertions(+), 25 deletions(-)

Core:

• src/core/segments/git.rs (+52, -11)
• src/core/statusline.rs (+9, -1)

TUI:

• src/ui/app.rs (+58, -3)
• src/ui/components/preview.rs (+58, -11)
• src/ui/components/segment_list.rs (+3)
• src/ui/components/settings.rs (+34)

Themes (9 files, +1 line each):

• All theme files in src/ui/themes/

Commits

1. feat: add dirty file count display to git segment (30b9778)

   • Core implementation in Git segment
   • Theme configuration updates

2. feat(tui): add Git segment options to TUI configurator (3aca994)

   • TUI integration for both show_sha and show_dirty_count
   • Field navigation and toggle handlers

3. fix(tui): update Git segment preview to reflect options (7e6a419)

   • Preview component now respects Git options
   • Real-time feedback when toggling

---

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com

Summary by Sourcery

Introduce dirty file count to the Git segment and add two new usage tracking segments with customizable threshold-based warnings; refactor color and threshold logic into shared utilities, extend TUI and themes to support the new options, and update documentation and versioning.

New Features:

• Add dirty file count display to Git segment with toggleable option
• Introduce dedicated Usage5Hour and Usage7Day segments for focused API usage tracking
• Enable threshold-based warning and critical colors and bold styling for usage segments

Enhancements:

• Refactor ANSI color conversion into a shared color_utils module
• Centralize threshold logic in threshold_utils and apply metadata-driven styling overrides in statusline
• Expose public helpers for reset time formatting and shared API usage cache loading
• Integrate new Git and usage options into the TUI configurator and extend theme presets accordingly

Build:

• Bump version to 1.0.9 in Cargo.toml

Documentation:

• Update README with new usage segments and threshold-based color configuration
• Add changelog entry for version 1.0.9

[sourcery-ai]

Reviewer's Guide

This PR extends the Git segment to optionally show the count of dirty files, introduces two dedicated usage segments with threshold-based warning/critical colors, adds shared utilities for color and threshold handling, and updates the TUI configurator, theme presets, and documentation to expose and preview these new features.

Class diagram for new and updated segment types

classDiagram
    class GitSegment {
        +bool show_sha
        +bool show_dirty_count
        +with_sha(show_sha: bool) GitSegment
        +with_dirty_count(show_dirty_count: bool) GitSegment
        +collect(input: InputData) Option<SegmentData>
    }
    class GitInfo {
        +String branch
        +GitStatus status
        +u32 ahead
        +u32 behind
        +Option<String> sha
        +u32 dirty_count
    }
    class UsageSegment {
        +collect(input: InputData) Option<SegmentData>
        +static load_usage_cache() Option<ApiUsageCache>
        +static get_circle_icon(utilization: f64) String
        +static format_5hour_reset_time(reset_time_str: Option<&str>) String
        +static format_7day_reset_time(reset_time_str: Option<&str>) String
    }
    class ApiUsageCache {
        +f64 five_hour_utilization
        +f64 seven_day_utilization
        +Option<String> five_hour_resets_at
        +Option<String> seven_day_resets_at
        +String cached_at
    }
    class Usage5HourSegment {
        +collect(input: InputData) Option<SegmentData>
    }
    class Usage7DaySegment {
        +collect(input: InputData) Option<SegmentData>
    }
    Usage5HourSegment --|> Segment
    Usage7DaySegment --|> Segment
    UsageSegment --|> Segment
    GitSegment --|> Segment
    GitSegment --> GitInfo
    UsageSegment --> ApiUsageCache
    Usage5HourSegment --> UsageSegment
    Usage7DaySegment --> UsageSegment
    ApiUsageCache <.. UsageSegment

Loading

File-Level Changes

Change	Details	Files
Add dirty file count support to Git segment	Extend GitInfo with a dirty_count field Change get_status() to return (GitStatus, count) Add with_dirty_count() builder and store count in metadata Update collect() formatting to show “● N” or “⚠ N” when enabled	src/core/segments/git.rs
Integrate show_dirty_count option into segment collection and statusline	Read show_dirty_count from config and pass to GitSegment::with_dirty_count Parse metadata.text_color_override and text_bold_override in StatusLineGenerator Apply these overrides when styling primary/secondary text	src/core/statusline.rs
Implement dedicated 5-hour and 7-day usage segments with threshold logic	Split API cache struct to store separate reset times Add load_usage_cache(), format_5hour_reset_time(), format_7day_reset_time() helpers Create Usage5HourSegment and Usage7DaySegment modules sharing cache Enhance context_window to support threshold color and bold overrides	src/core/segments/usage.rs src/core/segments/usage_5hour.rs src/core/segments/usage_7day.rs src/core/segments/context_window.rs
Introduce shared utilities for color serialization and threshold lookup	Create color_utils.rs to convert AnsiColor↔ratatui Color and serialize to JSON Create threshold_utils.rs to cache config and compute warning/critical color/bold based on utilization	src/core/segments/color_utils.rs src/core/segments/threshold_utils.rs
Extend TUI configurator and preview to expose Git and threshold options	Add ShowSha and ShowDirtyCount to FieldSelection enum Update SettingsComponent to render checkboxes for new options and threshold fields Adjust App navigation, constants and toggle handlers for Git and usage thresholds Enhance preview generator to mock Git dirty count and threshold-based colors	src/ui/components/segment_list.rs src/ui/components/settings.rs src/ui/app.rs src/ui/components/preview.rs
Update themes, presets, and documentation for new features	Enable show_dirty_count by default in all 9 theme files Add usage_5hour and usage_7day segments to presets.rs Document Git dirty count and usage segments in README Record new version and features in CHANGELOG	src/ui/themes/theme_*.rs src/ui/themes/presets.rs README.md CHANGELOG.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• The SettingsComponent and App logic for segment‐specific fields (Git vs. usage thresholds) has grown quite large and repetitive—consider refactoring into smaller helper functions or a data-driven table so adding/removing options is easier.
• All nine theme files contain nearly identical boilerplate for the new usage_5hour and usage_7day segments—extract a shared helper or macro to generate those presets and reduce manual duplication.
• threshold_utils caches the Config in a global OnceCell without ever invalidating it, so changes to the TOML won’t take effect in the running TUI—consider exposing a cache-invalidate hook or reloading logic when the config is updated.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The SettingsComponent and App logic for segment‐specific fields (Git vs. usage thresholds) has grown quite large and repetitive—consider refactoring into smaller helper functions or a data-driven table so adding/removing options is easier.
- All nine theme files contain nearly identical boilerplate for the new usage_5hour and usage_7day segments—extract a shared helper or macro to generate those presets and reduce manual duplication.
- threshold_utils caches the Config in a global OnceCell without ever invalidating it, so changes to the TOML won’t take effect in the running TUI—consider exposing a cache-invalidate hook or reloading logic when the config is updated.

## Individual Comments

### Comment 1
<location> `src/core/segments/usage.rs:70` </location>
<code_context>

-    fn get_cache_path() -> Option<std::path::PathBuf> {
+    /// Format 5-hour reset time as "11am" or "5pm"
+    pub fn format_5hour_reset_time(reset_time_str: Option<&str>) -> String {
+        if let Some(time_str) = reset_time_str {
+            if let Ok(dt) = DateTime::parse_from_rfc3339(time_str) {
</code_context>

<issue_to_address>
**suggestion:** Consider handling time zone edge cases for reset time formatting.

If time zone differences are possible, please clarify or document how reset times are handled for users in various time zones.
</issue_to_address>

### Comment 2
<location> `src/core/segments/usage.rs:161` </location>
<code_context>
     }

+    /// Public helper to load cache for other usage segments
+    pub fn load_usage_cache() -> Option<ApiUsageCache> {
+        let cache_path = Self::get_cache_path()?;
+        if !cache_path.exists() {
</code_context>

<issue_to_address>
**suggestion (performance):** Repeated file reads may impact performance if called frequently.

Consider caching the loaded usage data in memory during a render cycle, or implementing a cache invalidation strategy to avoid repeated disk reads.

Suggested implementation:

```rust
    use once_cell::sync::OnceCell;
    use std::sync::Mutex;

    static USAGE_CACHE: OnceCell<Mutex<Option<ApiUsageCache>>> = OnceCell::new();

    /// Public helper to load cache for other usage segments
    pub fn load_usage_cache() -> Option<ApiUsageCache> {
        let cache = USAGE_CACHE.get_or_init(|| Mutex::new(None));
        let mut cache_guard = cache.lock().unwrap();

        if cache_guard.is_some() {
            return cache_guard.clone();
        }

        let cache_path = Self::get_cache_path()?;
        if !cache_path.exists() {
            return None;
        }

        let content = std::fs::read_to_string(&cache_path).ok()?;
        let parsed = serde_json::from_str(&content).ok();
        *cache_guard = parsed.clone();
        parsed
    }

```

```rust
    fn save_cache(&self, cache: &ApiUsageCache) {
        if let Some(cache_path) = Self::get_cache_path() {
            if let Some(parent) = cache_path.parent() {
                // Invalidate and update the in-memory cache after saving
                if let Some(cell) = USAGE_CACHE.get() {
                    let mut cache_guard = cell.lock().unwrap();
                    *cache_guard = Some(cache.clone());
                }
            }

```

- You may need to add `once_cell = "1.17"` (or latest) to your `Cargo.toml` dependencies.
- Ensure `ApiUsageCache` implements `Clone` if it does not already.
- If you want to support cache invalidation on file changes outside this process, consider adding a timestamp or file watcher.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion (performance): Repeated file reads may impact performance if called frequently.

Consider caching the loaded usage data in memory during a render cycle, or implementing a cache invalidation strategy to avoid repeated disk reads.

Suggested implementation:

    use once_cell::sync::OnceCell;
    use std::sync::Mutex;

    static USAGE_CACHE: OnceCell<Mutex<Option<ApiUsageCache>>> = OnceCell::new();

    /// Public helper to load cache for other usage segments
    pub fn load_usage_cache() -> Option<ApiUsageCache> {
        let cache = USAGE_CACHE.get_or_init(|| Mutex::new(None));
        let mut cache_guard = cache.lock().unwrap();

        if cache_guard.is_some() {
            return cache_guard.clone();
        }

        let cache_path = Self::get_cache_path()?;
        if !cache_path.exists() {
            return None;
        }

        let content = std::fs::read_to_string(&cache_path).ok()?;
        let parsed = serde_json::from_str(&content).ok();
        *cache_guard = parsed.clone();
        parsed
    }

    fn save_cache(&self, cache: &ApiUsageCache) {
        if let Some(cache_path) = Self::get_cache_path() {
            if let Some(parent) = cache_path.parent() {
                // Invalidate and update the in-memory cache after saving
                if let Some(cell) = USAGE_CACHE.get() {
                    let mut cache_guard = cell.lock().unwrap();
                    *cache_guard = Some(cache.clone());
                }
            }

• You may need to add once_cell = "1.17" (or latest) to your Cargo.toml dependencies.
• Ensure ApiUsageCache implements Clone if it does not already.
• If you want to support cache invalidation on file changes outside this process, consider adding a timestamp or file watcher.