jnsahaj / lumen

Instant AI Git Commit message, Git changes summary from the CLI (no API key required)
MIT License
290 stars 10 forks source link

Project specific configuration? #9

Open jmattaa opened 4 days ago

jmattaa commented 4 days ago

It would've been nice to have a configuration file for a git project (placed in for example GIT_DIRECTORY/lumen_config), where one could customise the tool to be for a specific project. My idea is to be able to customise options such as:

  1. AI model config: where one could specify the provider, model and key for one project.
  2. Commit message prefix: Here it would be nice to customize the conventional_types to match a projects guidlines.
        let conventional_types = r#"{
                    "docs": "Documentation only changes",
                    "style": "Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)",
                    "refactor": "A code change that neither fixes a bug nor adds a feature",
                    "perf": "A code change that improves performance",
                    "test": "Adding missing tests or correcting existing tests",
                    "build": "Changes that affect the build system or external dependencies",
                    "ci": "Changes to our CI configuration files and scripts",
                    "chore": "Other changes that don't modify src or test files",
                    "revert": "Reverts a previous commit",
                    "feat": "A new feature",
                    "fix": "A bug fix"
                }"#;

A config file could look something like

model_provider = "OpenAI"
model = "gpt-4o"
api_key = {api key}

prefix.docs = "Documentation only changes"
prefix.style = "Changes that do not affect the meaning of the code"
prefix.refactor = "A code change that neither fixes a bug nor adds a feature"
prefix.fix = "A bug fix"
// and other options

And an implementation of this in the project could look like

struct Config {
    model_provider: String,
    model: String,
    api_key: String,
    conventional_types: HashMap<String, String>,
}

I feel that this could be handy, for me but I'm unsure if it will be usable, it would be nice to have the option to do that. I could open a pr and implement something resembling this idea.

(I just saw that the project relies on serde_json, so the config could even be written in json)

jnsahaj commented 4 days ago

Sounds like a good idea. Should be pretty standard to implement.

So there will be an abstracted Config service that gets us the required points you mentioned, instead of reading them from cli

The precedence should be: cli flags > git_dir > env vars

You can work on this if you would like to. The only points that are subject to change is the API itself for the config. But I agree that we should start with JSON