feature: added new argument --commit-template-file

[dejecj]

Addresses #352

This PR adds a new argument

--commit-template-file

Use this argument to specify the path to a template file.

If argument is not provided the it will default to the following template:

{aider.prefix}: {aider.commit_message}

{aider.context}

The default behavior is unchanged as far as the structure of commit messages when the template file is not provided.

The 3 "tags" shown in the default template are dynamically replaced with their actual contents based on the outputs of aider. These can be omitted but it's recommended to at minimum include the {aider.commit_message} tag.

In addition to these default tags the template supports any number of {user.**} tags. For example I can replace the default prefix like so:

{user.myprefix}: {aider.commit_message}

{aider.context}

When you introduce a {user.**} tag to the template aider will ask you for the values to inject into the template on startup.

The provided template file is not allowed to be empty and it must exists or aider will exit with an error.

[carlos-dc]

@paul-gauthier Just a bump on this, can I get your thoughts on this idea?

[paul-gauthier]

Thanks for putting this together. I don't think I can merge it.

Your changes don't take into account that fact that Repo.commit() is called for more than just aider/GPT commits. It is also used to commit dirty files that have user changes before applying GPT edits.

[dejecj]

Thanks for putting this together. I don't think I can merge it.

Your changes don't take into account that fact that Repo.commit() is called for more than just aider/GPT commits. It is also used to commit dirty files that have user changes before applying GPT edits.

Hey thanks for taking a look. I'm likely missing your point since I don't have as much project knowledge as you. I tried to not break functionality by falling back to the old message structure if a template file has not been presented (aka setting the old message structure as a default template string in code) while in the auto_commit method. For clarity, are you saying that there are other methods besides auto_commit that invoke the Repo.commit method? That being the case this definitely doesn't account for that and it would for sure break. If there are, could you maybe tell me which methods would also need modification? I would gladly make necessary changes there as well. @paul-gauthier

[karimStekelenburg]

I would love to see this feature as well! I think what @paul-gauthier is referring to is this, which will make sure any user edits are committed before the AI does its thing.

Personally, I'd like to have this feature so Aider will use conventional commit messages. Looking at the title of your PR and branch you are looking to do the same @dejecj. If this is the case, however, passing a static template may not be ideal because the prefix is dependent on the type of change that is being committed.

One approach to solve this would be to have an LLM look at the diff and ask it to determine the type of change and the appropriate prefix (e.g. feat, refactor, fix, etc.). Although this method is specific to conventional commits, it could also solve the problems regarding the dirty commits mentioned by @paul-gauthier. The LLM could inspect the diff of the changes made by the user, determine the prefix and appropriate commit message/content, and make the commit.

As said, this approach is very specific to conventional commits and not as flexible as the template approach. It would probably require a dedicated flag like --use-conventional-commits or something similar and I can imagine this use case being disregarded as being too niche to include it into the core of the project. That being said, there are a lot of open source projects that enforce the use of conventional commits, including the ones I work on. Maybe a plugin/extension based approach that allows for passing a prompt for formatting commit messages is the way to go? That way, no matter who made the changes (Aider or the User), the same prompt can be applied.

Example
Passing the (optional) prompt template like --commit-message-prompt-template ./template.txt. In the case of conventional commits, the template.txt file might look something like this:

You are tasked to generate and format a GIT commit message based on a diff. You will format the message using the conventional commit standard. There are the steps you should take:

1. Analyse the diff and determine the type of the change. Classify the change as one of the following options and take note of the corresponding prefix.
    - Feature - (prefix: feat)
    - Refactor - (prefix: refactor)
    - Bugfix - (prefix: fix)
    - .....
2. Analyse the "diff" to determine an appropriate commit message. Keep it concise and make sure it doesn't exceed 60 characters.
3. Analyse the "diff" to and generate a concise summary of the changes being made.

After executing these steps, you will format the message as follows. You will replace "[prefix]" with the prefix determined in step 1. You will replace "[message]" with the commit message determined in step 2. Finally, you will replace "[content]" with the summary generated in step 3. You will respond with the formatted message ONLY. You WILL NOT include anything else.

Here is the format template:

---
[prefix]: [message]

[content]
---

Here is the diff view:

{diff}

START!

This obviously is a simplified example, but I think it gives a rough idea.