feat(cli): add dotfiles command for managing configuration files

[AnnatarHe]

Summary

• Added new dotfiles command with push subcommand for managing and syncing configuration files
• Supports 6 popular applications: nvim, fish, git, zsh, bash, and ghostty
• Implements modular architecture with extensible app handlers

Features

• Push dotfiles to server: shelltime dotfiles push pushes all supported app configs
• Selective push: shelltime dotfiles push --apps nvim,git pushes only specified apps
• Automatic file collection: Recursively collects configs from standard locations
• Metadata tracking: Captures file modification times and hostname
• Web management: Provides link to manage dotfiles at /users/{userID}/settings/dotfiles

Implementation Details

• Created DotfileApp interface for extensible app support
• Each app has its own handler file in the model package for maintainability
• Reuses existing API client infrastructure with msgpack encoding
• Follows project conventions for error handling and logging

Test plan

• Build the CLI: go build -o shelltime ./cmd/cli/main.go
• Test help command: ./shelltime dotfiles --help
• Test push help: ./shelltime dotfiles push --help
• Test pushing all dotfiles: ./shelltime dotfiles push
• Test selective push: ./shelltime dotfiles push --apps git,nvim
• Verify data arrives at server endpoint /api/v1/dotfiles/push
• Check web link generation and access

🤖 Generated with Claude Code

[claude]

Claude finished @AnnatarHe's task —— View job

---

Code Review Complete ✅

I've thoroughly reviewed the dotfiles command implementation. Here's my comprehensive feedback:

Review Checklist:

• Read and analyze all changed files
• Review code quality and architecture
• Check for potential bugs and edge cases
• Assess security concerns (file handling, path traversal)
• Evaluate performance considerations
• Check test coverage and testing approach
• Provide comprehensive feedback

---

Overall Assessment

Strengths:

• Clean, modular architecture with extensible DotfileApp interface
• Follows existing project conventions (logging, error handling, API client patterns)
• Good separation of concerns between command handling and business logic
• Proper use of context throughout the call chain

Code Quality & Architecture ⭐⭐⭐⭐⭐

Excellent Design Patterns:

• Interface-based architecture (DotfileApp) allows easy extension for new applications
• BaseApp struct provides excellent code reuse for common operations
• Each app handler is in its own file, maintaining good organization
• Reuses existing SendHTTPRequest infrastructure with proper msgpack encoding

Minor Improvements:

• Consider adding validation for app names in commands/dotfiles.go:82-87 to provide better user feedback for typos
• The OnUsageError function in commands/dotfiles.go:31-33 returns nil - consider returning the error for proper CLI behavior

Security Analysis 🔒

Good Security Practices:

• Path expansion logic in model/dotfile_apps.go:25-34 properly handles ~ home directory expansion
• Uses filepath.Join and filepath.Abs for safe path handling
• File operations are properly error-checked

Security Concerns:

• Path Traversal Risk: The directory walking logic in model/dotfile_apps.go:122-131 could potentially access files outside intended directories if symbolic links point elsewhere. Consider adding symlink validation or using filepath.EvalSymlinks
• File Size Limits: No limits on file size when reading configurations. Large files could cause memory issues. Consider adding size checks before reading.

Potential Bugs & Edge Cases 🐛

Identified Issues:

1. Silent Directory Failures: In model/dotfile_apps.go:124, errors from filepath.Walk are ignored with return nil. This could hide permission issues or other problems. Consider logging warnings:

   if err != nil {
       logrus.Debugf("Error walking directory %s: %v", path, err)
       return nil
   }

2. Empty Results Handling: If a user specifies apps that don't exist on their system, they get warnings but the command succeeds with 0 files. Consider making this more explicit.

3. Hostname Duplication: In model/dotfile.go:57 and model/dotfile_apps.go:57, hostname is retrieved twice. This is inefficient and could lead to inconsistent values if hostname changes during execution.

Performance Considerations ⚡

Potential Issues:

• Large Directory Traversal: Nvim and zsh configs include entire directories (~/.config/nvim, ~/.config/zsh). For users with large configurations, this could be slow. Consider:
  • Adding progress indicators for large directory scans
  • Implementing file filtering (e.g., ignore .git directories, binary files)
  • Adding configuration limits

Memory Usage:

• All file contents are loaded into memory before sending. For large dotfile collections, consider streaming or chunking the upload.

Test Coverage 📊

Missing Tests:
The implementation lacks comprehensive tests. Consider adding:

1. Unit Tests for Each App Handler:

   func TestBashApp_GetConfigPaths(t *testing.T) {
       app := NewBashApp()
       paths := app.GetConfigPaths()
       assert.Contains(t, paths, "~/.bashrc")
   }

2. Integration Tests for File Collection:

   • Test with missing files/directories
   • Test with permission errors
   • Test path expansion with different home directory setups

3. API Client Tests:

   • Mock HTTP server testing for SendDotfilesToServer
   • Test error handling scenarios

Specific Recommendations

1. Add File Size Limits (model/dotfile_apps.go:36-54):

   const maxFileSize = 10 << 20 // 10MB
   if fileInfo.Size() > maxFileSize {
       return "", nil, fmt.Errorf("file %s too large: %d bytes", path, fileInfo.Size())
   }

2. Improve Directory Walking (model/dotfile_apps.go:122-131):

   func (b *BaseApp) collectFromDirectory(dir string) ([]string, error) {
       var files []string
       err := filepath.Walk(dir, func(path string, info os.FileInfo, err error) error {
           if err != nil {
               logrus.Debugf("Error accessing %s: %v", path, err)
               return nil // Skip problematic paths
           }
           
           // Skip hidden files and common ignore patterns
           if info.IsDir() || strings.HasPrefix(info.Name(), ".") || 
              strings.HasSuffix(info.Name(), ".tmp") {
               return nil
           }
           
           // Check for reasonable file size
           if info.Size() > maxFileSize {
               logrus.Warnf("Skipping large file %s (%d bytes)", path, info.Size())
               return nil
           }
           
           files = append(files, path)
           return nil
       })
       return files, err
   }

3. Add Progress Feedback for better UX when processing large configurations.

Final Verdict

This is a well-architected feature that follows good design principles and integrates cleanly with the existing codebase. The modular approach makes it easy to add support for new applications. Address the security concerns around path traversal and consider adding the suggested error handling improvements.

Recommendation: Approve with suggested improvements 🚀

---

[gemini-code-assist]

Summary of Changes

Hello @AnnatarHe, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant new feature to the shelltime CLI: the ability to manage and synchronize user configuration files, commonly known as dotfiles. The primary goal is to simplify the process of backing up and restoring personal development environments by providing a command-line interface to push these files to a central server. The implementation emphasizes extensibility, allowing for straightforward addition of support for more applications in the future.

Highlights

• New CLI Command: Introduced a new dotfiles command to the CLI, with a push subcommand for managing and syncing configuration files.
• Application Support: The dotfiles command supports syncing configuration files for 6 popular applications: nvim, fish, git, zsh, bash, and ghostty.
• Flexible Push Options: Users can push all supported dotfiles or selectively push configurations for specific applications using the --apps flag.
• Automatic File Collection: The system automatically collects dotfiles by recursively scanning standard configuration locations for each supported application.
• Modular Architecture: The implementation uses a modular design with an DotfileApp interface, making it easy to extend support for additional applications in the future.
• Web Management Integration: After pushing, the CLI provides a direct link to a web interface where users can manage their synchronized dotfiles.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new dotfiles command for managing configuration files, which is a great feature. The code is well-structured, using an interface-based approach to support different applications. However, I've identified a few important issues. There's a critical logic error in the file collection that causes it to skip dotfiles, which needs to be fixed. Additionally, the command currently suppresses usage errors, and there's a potential resource leak due to how the logger is initialized. I've also left some comments on improving error handling and removing redundant code.

[gemini-code-assist]

Swallowing usage errors by returning nil provides a poor user experience, as users won't be notified of incorrect command usage. It's better to remove this OnUsageError handler and let the urfave/cli framework provide its default, helpful error messages.

[gemini-code-assist]

Calling SetupLogger here can lead to resource leaks. The implementation in commands/logger.go opens a file handle but does not handle being called multiple times within the same process execution. Logger initialization should be performed once, centrally, at the application's startup in main().

[gemini-code-assist]

The condition !strings.HasPrefix(info.Name(), ".") filters out all files starting with a dot. Since this command is for managing "dotfiles", this is likely incorrect as it would skip files like .gitignore or other hidden configuration files within a directory. This check should probably be removed to ensure all relevant configuration files are collected.

if !info.IsDir() {

[gemini-code-assist]

The hostname is retrieved here, but SendDotfilesToServer also handles setting it if it's missing. This is redundant work and couples this function with knowledge it doesn't need. To improve separation of concerns, the hostname logic should be centralized in SendDotfilesToServer. Please remove this line and the corresponding Hostname field assignments on lines 95 and 112.

[gemini-code-assist]

Errors encountered during filepath.Walk are being swallowed by just returning nil. This can hide underlying filesystem issues, such as permission errors, making debugging difficult. These errors should be logged before continuing the walk.

logrus.Debugf("Error accessing path %s: %v", path, err)
return nil // Continue walking, but log the error

[claude]

Claude finished @AnnatarHe's task —— View job

---

Code Review Complete ✅

I've thoroughly reviewed the dotfiles command implementation. Here's my comprehensive feedback:

Review Checklist:

• Read and analyze all changed files
• Review code quality and architecture
• Check for potential bugs and edge cases
• Assess security concerns (file handling, path traversal)
• Evaluate performance considerations
• Check test coverage and testing approach
• Provide comprehensive feedback

---

Overall Assessment

Strengths:

• Clean, modular architecture with extensible DotfileApp interface
• Follows existing project conventions (logging, error handling, API client patterns)
• Good separation of concerns between command handling and business logic
• Proper use of context throughout the call chain

Code Quality & Architecture ⭐⭐⭐⭐⭐

Excellent Design Patterns:

• Interface-based architecture (DotfileApp) allows easy extension for new applications
• BaseApp struct provides excellent code reuse for common operations
• Each app handler is in its own file, maintaining good organization
• Reuses existing SendHTTPRequest infrastructure with proper msgpack encoding

Minor Improvements:

• Consider adding validation for app names in commands/dotfiles.go:82-87 to provide better user feedback for typos
• The OnUsageError function in commands/dotfiles.go:31-33 returns nil - consider returning the error for proper CLI behavior

Security Analysis 🔒

Good Security Practices:

• Path expansion logic in model/dotfile_apps.go:25-34 properly handles ~ home directory expansion
• Uses filepath.Join and filepath.Abs for safe path handling
• File operations are properly error-checked

Security Concerns:

• Path Traversal Risk: The directory walking logic in model/dotfile_apps.go:122-131 could potentially access files outside intended directories if symbolic links point elsewhere. Consider adding symlink validation or using filepath.EvalSymlinks
• File Size Limits: No limits on file size when reading configurations. Large files could cause memory issues. Consider adding size checks before reading.

Potential Bugs & Edge Cases 🐛

Identified Issues:

1. Silent Directory Failures: In model/dotfile_apps.go:124, errors from filepath.Walk are ignored with return nil. This could hide permission issues or other problems. Consider logging warnings:

   if err != nil {
       logrus.Debugf("Error walking directory %s: %v", path, err)
       return nil
   }

2. Empty Results Handling: If a user specifies apps that don't exist on their system, they get warnings but the command succeeds with 0 files. Consider making this more explicit.

3. Hostname Duplication: In model/dotfile.go:57 and model/dotfile_apps.go:57, hostname is retrieved twice. This is inefficient and could lead to inconsistent values if hostname changes during execution.

Performance Considerations ⚡

Potential Issues:

• Large Directory Traversal: Nvim and zsh configs include entire directories (~/.config/nvim, ~/.config/zsh). For users with large configurations, this could be slow. Consider:
  • Adding progress indicators for large directory scans
  • Implementing file filtering (e.g., ignore .git directories, binary files)
  • Adding configuration limits

Memory Usage:

• All file contents are loaded into memory before sending. For large dotfile collections, consider streaming or chunking the upload.

Test Coverage 📊

Missing Tests:
The implementation lacks comprehensive tests. Consider adding:

1. Unit Tests for Each App Handler:

   func TestBashApp_GetConfigPaths(t *testing.T) {
       app := NewBashApp()
       paths := app.GetConfigPaths()
       assert.Contains(t, paths, "~/.bashrc")
   }

2. Integration Tests for File Collection:

   • Test with missing files/directories
   • Test with permission errors
   • Test path expansion with different home directory setups

3. API Client Tests:

   • Mock HTTP server testing for SendDotfilesToServer
   • Test error handling scenarios

Specific Recommendations

1. Add File Size Limits (model/dotfile_apps.go:36-54):

   const maxFileSize = 10 << 20 // 10MB
   if fileInfo.Size() > maxFileSize {
       return "", nil, fmt.Errorf("file %s too large: %d bytes", path, fileInfo.Size())
   }

2. Improve Directory Walking (model/dotfile_apps.go:122-131):

   func (b *BaseApp) collectFromDirectory(dir string) ([]string, error) {
       var files []string
       err := filepath.Walk(dir, func(path string, info os.FileInfo, err error) error {
           if err != nil {
               logrus.Debugf("Error accessing %s: %v", path, err)
               return nil // Skip problematic paths
           }
           
           // Skip hidden files and common ignore patterns
           if info.IsDir() || strings.HasPrefix(info.Name(), ".") || 
              strings.HasSuffix(info.Name(), ".tmp") {
               return nil
           }
           
           // Check for reasonable file size
           if info.Size() > maxFileSize {
               logrus.Warnf("Skipping large file %s (%d bytes)", path, info.Size())
               return nil
           }
           
           files = append(files, path)
           return nil
       })
       return files, err
   }

3. Add Progress Feedback for better UX when processing large configurations.

Final Verdict

This is a well-architected feature that follows good design principles and integrates cleanly with the existing codebase. The modular approach makes it easy to add support for new applications. Address the security concerns around path traversal and consider adding the suggested error handling improvements.

Recommendation: Approve with suggested improvements 🚀

---

[claude]

Claude finished @AnnatarHe's task —— View job

---

Code Review Complete ✅

I've thoroughly reviewed the dotfiles command implementation. Here's my comprehensive feedback:

Review Checklist:

• Read and analyze all changed files
• Review code quality and architecture
• Check for potential bugs and edge cases
• Assess security concerns (file handling, path traversal)
• Evaluate performance considerations
• Check test coverage and testing approach
• Provide comprehensive feedback

---

Overall Assessment

Strengths:

• Clean, modular architecture with extensible DotfileApp interface
• Follows existing project conventions (logging, error handling, API client patterns)
• Good separation of concerns between command handling and business logic
• Proper use of context throughout the call chain

Code Quality & Architecture ⭐⭐⭐⭐⭐

Excellent Design Patterns:

• Interface-based architecture (DotfileApp) allows easy extension for new applications
• BaseApp struct provides excellent code reuse for common operations
• Each app handler is in its own file, maintaining good organization
• Reuses existing SendHTTPRequest infrastructure with proper msgpack encoding

Minor Improvements:

• Consider adding validation for app names in commands/dotfiles.go:82-87 to provide better user feedback for typos
• The OnUsageError function in commands/dotfiles.go:31-33 returns nil - consider returning the error for proper CLI behavior

Security Analysis 🔒

Good Security Practices:

• Path expansion logic in model/dotfile_apps.go:25-34 properly handles ~ home directory expansion
• Uses filepath.Join and filepath.Abs for safe path handling
• File operations are properly error-checked

Security Concerns:

• Path Traversal Risk: The directory walking logic in model/dotfile_apps.go:122-131 could potentially access files outside intended directories if symbolic links point elsewhere. Consider adding symlink validation or using filepath.EvalSymlinks
• File Size Limits: No limits on file size when reading configurations. Large files could cause memory issues. Consider adding size checks before reading.

Potential Bugs & Edge Cases 🐛

Identified Issues:

1. Silent Directory Failures: In model/dotfile_apps.go:124, errors from filepath.Walk are ignored with return nil. This could hide permission issues or other problems. Consider logging warnings:

   if err != nil {
       logrus.Debugf("Error walking directory %s: %v", path, err)
       return nil
   }

2. Empty Results Handling: If a user specifies apps that don't exist on their system, they get warnings but the command succeeds with 0 files. Consider making this more explicit.

3. Hostname Duplication: In model/dotfile.go:57 and model/dotfile_apps.go:57, hostname is retrieved twice. This is inefficient and could lead to inconsistent values if hostname changes during execution.

Performance Considerations ⚡

Potential Issues:

• Large Directory Traversal: Nvim and zsh configs include entire directories (~/.config/nvim, ~/.config/zsh). For users with large configurations, this could be slow. Consider:
  • Adding progress indicators for large directory scans
  • Implementing file filtering (e.g., ignore .git directories, binary files)
  • Adding configuration limits

Memory Usage:

• All file contents are loaded into memory before sending. For large dotfile collections, consider streaming or chunking the upload.

Test Coverage 📊

Missing Tests:
The implementation lacks comprehensive tests. Consider adding:

1. Unit Tests for Each App Handler:

   func TestBashApp_GetConfigPaths(t *testing.T) {
       app := NewBashApp()
       paths := app.GetConfigPaths()
       assert.Contains(t, paths, "~/.bashrc")
   }

2. Integration Tests for File Collection:

   • Test with missing files/directories
   • Test with permission errors
   • Test path expansion with different home directory setups

3. API Client Tests:

   • Mock HTTP server testing for SendDotfilesToServer
   • Test error handling scenarios

Specific Recommendations

1. Add File Size Limits (model/dotfile_apps.go:36-54):

   const maxFileSize = 10 << 20 // 10MB
   if fileInfo.Size() > maxFileSize {
       return "", nil, fmt.Errorf("file %s too large: %d bytes", path, fileInfo.Size())
   }

2. Improve Directory Walking (model/dotfile_apps.go:122-131):

   func (b *BaseApp) collectFromDirectory(dir string) ([]string, error) {
       var files []string
       err := filepath.Walk(dir, func(path string, info os.FileInfo, err error) error {
           if err != nil {
               logrus.Debugf("Error accessing %s: %v", path, err)
               return nil // Skip problematic paths
           }
           
           // Skip hidden files and common ignore patterns
           if info.IsDir() || strings.HasPrefix(info.Name(), ".") || 
              strings.HasSuffix(info.Name(), ".tmp") {
               return nil
           }
           
           // Check for reasonable file size
           if info.Size() > maxFileSize {
               logrus.Warnf("Skipping large file %s (%d bytes)", path, info.Size())
               return nil
           }
           
           files = append(files, path)
           return nil
       })
       return files, err
   }

3. Add Progress Feedback for better UX when processing large configurations.

Final Verdict

This is a well-architected feature that follows good design principles and integrates cleanly with the existing codebase. The modular approach makes it easy to add support for new applications. Address the security concerns around path traversal and consider adding the suggested error handling improvements.

Recommendation: Approve with suggested improvements 🚀

---

[codecov]

Codecov Report

❌ Patch coverage is 8.57143% with 288 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
model/dotfile_apps.go	0.00%	81 Missing ⚠️
commands/dotfiles.go	0.00%	76 Missing ⚠️
model/dotfile.go	0.00%	39 Missing ⚠️
model/config.go	60.00%	12 Missing and 6 partials ⚠️
model/dotfile_bash.go	0.00%	13 Missing ⚠️
model/dotfile_git.go	0.00%	13 Missing ⚠️
model/dotfile_zsh.go	0.00%	13 Missing ⚠️
model/dotfile_fish.go	0.00%	12 Missing ⚠️
model/dotfile_ghostty.go	0.00%	11 Missing ⚠️
model/dotfile_nvim.go	0.00%	11 Missing ⚠️
... and 1 more

Flag	Coverage Δ
unittests	22.10% <8.57%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
cmd/cli/main.go	0.00% <0.00%> (ø)
model/dotfile_ghostty.go	0.00% <0.00%> (ø)
model/dotfile_nvim.go	0.00% <0.00%> (ø)
model/dotfile_fish.go	0.00% <0.00%> (ø)
model/dotfile_bash.go	0.00% <0.00%> (ø)
model/dotfile_git.go	0.00% <0.00%> (ø)
model/dotfile_zsh.go	0.00% <0.00%> (ø)
model/config.go	62.35% <60.00%> (+62.35%)	⬆️
model/dotfile.go	0.00% <0.00%> (ø)
commands/dotfiles.go	0.00% <0.00%> (ø)
... and 1 more

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.