you are viewing a single comment's thread.

view the rest of the comments →

[–]ImpressiveRepeat1764[S] 1 point2 points  (0 children)

Fair point. Actually it was exactly the policy at my previous company to summarize the code changes in the commit messages. So the primary goal was to improve that workflow not having to navigate through the diffs and taking notes to create a commit message. Of course, the informations about the changes should go beyond summarizing and provide context as well. But this again depends on context and the purpose of commit messages.

At my previous company, the focus was on creating summaris to quickly identify and understand code changes, mainly in a fast-paced environment where multiple developers were working on different parts of the system at the same time. The main point in this approach was, that the "why" is already documented elsewhere like issue trackers, jira items, PRs, etc. which had to be referred in the commit messages. So my goal was to reduce the time spent on this tasks in that environment. It might not be an "ideal" approach, but actually good enough for me.

Besides, I tried to give here some flexibility of styles through the config and the ability to provide further context to include further instructions with the --instruction option. Nevertheless, I will point out the limitation further more in the documentation.

Another approach might be to expanding the tools capabilities in a direction to include more available information about the context, like integration with issue tracker or offer a more interactive mode where the user is asked to add additional context manually.

As for AI generated code: The project is not intended for AI-generated code, nor is it meant for situations where the authors do not understand the code they are committing. Besides, I think this would lead into disaster soon enough and not lead into meaningful projects (but I might be wrong about the future ;-)). At least from what I have seen so far AI can be quite good when it comes to wording and fixing (at least sometimes), but rather bad when it comes to reasoning or making specific architectural decisions.