theredfish / git-o-clock Goto Github PK

Here some global things to do to improve grm :

• too much unwrap without error verifications
• no tests : we definitely should add tests to the main functions. You can also take a look to #9

GRM can be run on both Linux and Windows. We should test the installation process and then run commands to verify the result on the standard output.

• Windows -> powershell
• Linux -> Bash
• Linux -> Zsh

We want to verify the build process on both Linux and Windows for stable, beta and nightly channels.

• Clippy (allow fails on nightly)
• Linux
• Mac OS
• windows

Hey! RustFest 2019 - We had a talk about async-std and "Do you know that Path use blocking operations?"

We have a lot of calls based on Path.

This feature is in connection with #19 . Add a section to the configuration file to configure patterns with the gitignore's extended glob syntax. See here and here.

A simple configuration file named grm.toml that we can parse with serde. We can start by a section to exclude folders and files from the search. More information in #18

Allow the user to configure (#19) the max-depth of the search. It could be :

• 0 : no limits
• 1 or more : a max depth will be applied during the search

We can do that with globwalk

This issue isn't really elaborate, I will update it later. Main idea :

• Cargo install grm
• Binary files in releases (in .zip?)

But first we need a stable and tested release.

We can improve the performances by using a multi-threaded search. We can explore multiple solutions :

• A default value based on the number of CPUs
• A CLI parameter
• A configuration file where we can set the maximum number of threads
• All of them

We currently have a bash completion script. It has been generated with Clap. Then the file has been updated to reflect our needs, so the process isn't completely automated. We also need to cover zsh.

• Find a way to automate the generation of completions script (based on Clap or not)
• Support ZSH
• Automate the generation in travis CI for future releases

After adding repositories with grm, users can move their projects or delete them. We can provide a simple command to clean the database. This command can take time, users need to be warned.

• grm clean
• Ask user to confirm the action with the list of repositories to remove
• Create a backup file with the list of removed paths from the database : grm-clean-[DATE]
• Remove non existing repositories from the database

When grm is start we run pending migrations. We should have a rollback system.

1. Delete any old grm.db.backup file
2. Make a backup of the sqlite file (by copying it as grm.db.backup). It will be used if the rollback fails, or if the migration breaks something
3. Rollback if an error occurs

See https://docs.rs/diesel_migrations/1.4.0/diesel_migrations/