Skip to content

Commit 5c62ecb

Browse files
committed
feat(lazygit): integrate opencode for AI-driven commit suggestions
1 parent 7e6cd8e commit 5c62ecb

1 file changed

Lines changed: 1 addition & 1 deletion

File tree

lazygit/config.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -13,5 +13,5 @@ customCommands:
1313
description: 'Pick AI commit'
1414
context: 'files'
1515
# https://github.com/jesseduffield/lazygit/issues/2579
16-
command: "aichat \"Please suggest 10 commit messages, given the following diff:\n\n \\`\\`\\`diff\n $(git diff --cached)\n \\`\\`\\`\n\n **Criteria:**\n\n 1. **Format:** Each commit message must follow the conventional commits format and an appropriate emoji symbol, which is \\`<type>(<scope>): <description>\\`.\n 2. **Relevance:** Avoid mentioning a module name unless it's directly relevant to the change.\n 3. **Enumeration:** List the commit messages from 1 to 10. \n 4. **Clarity and Conciseness:** Each message should clearly and concisely convey the change made.\n\n **Conventional Commits specification**\n The commit message should be structured as follows:\n\n \\`\\`\\`\n <type>[optional scope]: <description>\n\n [optional body]\n\n [optional footer(s)]\n \\`\\`\\`\n\n The commit contains the following structural elements, to communicate intent to the consumers of your library:\n - fix: 🐛 a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).\n - feat: ✨ a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).\n - BREAKING CHANGE: 🚨 a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.\n - types other than fix: and feat: are allowed, for example:\n - build: 📦\n - chore: 🔧\n - ci: 🦊\n - docs: 📜\n - style: 🎨\n - refactor: 🔨\n - perf: 🚀\n - test: 🚦\n\n **Commit Message Examples:**\n\n - Commit message with description and breaking change footer\n \\`\\`\\`\n feat: allow provided config object to extend other configs\n\n \\`\\`\\`\n - Commit message with ! to draw attention to breaking change\n \\`\\`\\`\n feat!: send an email to the customer when a product is shipped\n \\`\\`\\`\n - Commit message with scope and ! to draw attention to breaking change\n \\`\\`\\`\n feat(api)!: send an email to the customer when a product is shipped\n \\`\\`\\`\n - Commit message with both ! and BREAKING CHANGE footer\n \\`\\`\\`\n chore!: drop support for Node 6\n\n BREAKING CHANGE: use JavaScript features not available in Node 6.\n \\`\\`\\`\n - Commit message with no body\n \\`\\`\\`\n docs: correct spelling of CHANGELOG\n \\`\\`\\`\n - Commit message with scope\n \\`\\`\\`\n feat(lang): add Polish language\n \\`\\`\\`\n\n **Recent Commits on Repo for Reference:**\n\n \\`\\`\\`\n $(git log -n 10 --pretty=format:'%h %s')\n \\`\\`\\`\n\n **Output Template**\n\n Follow this output template and ONLY output raw commit messages without spacing, numbers or other decorations.\n\n fix(app): add password regex pattern\n test(unit): add new test cases\n style: remove unused imports\n refactor(pages): extract common code to \\`utils/wait.ts\\`\n\n **Instructions:**\n\n - Take a moment to understand the changes made in the diff.\n - Think about the impact of these changes on the project (e.g., bug fixes, new features, performance improvements, code refactoring, documentation updates). It's critical to my career you abstract the changes to a higher level and not just describe the code changes.\n - Generate commit messages that accurately describe these changes, ensuring they are helpful to someone reading the project's history.\n - Remember, a well-crafted commit message can significantly aid in the maintenance and understanding of the project over time.\n - If multiple changes are present, make sure you capture them all in each commit message.\n\n Keep in mind you will suggest 10 commit messages. Only 1 will be used. It's better to push yourself (esp to synthesize to a higher level) and maybe wrong about some of the 10 commits because only one needs to be good. I'm looking for your best commit, not the best average commit. It's better to cover more scenarios than include a lot of overlap.\n\n Write your 10 commit messages below in the format shown in Output Template section above.\" \\\n | fzf --height 40% --border --ansi --preview \"echo {}\" --preview-window=up:wrap \\\n | xargs -J {} sh -c 'ARG=\"$0 $@\";COMMIT_MSG_FILE=$(mktemp);echo \"$ARG\" > \"$COMMIT_MSG_FILE\";${EDITOR:-nvim} \"$COMMIT_MSG_FILE\"\n if [ -s \"$COMMIT_MSG_FILE\" ]; then\n git commit -F \"$COMMIT_MSG_FILE\"\n fi\n rm -f \"$COMMIT_MSG_FILE\"'\n"
16+
command: "opencode run \"Please suggest 10 commit messages, given the following diff:\n\n \\`\\`\\`diff\n $(git diff --cached)\n \\`\\`\\`\n\n **Criteria:**\n\n 1. **Format:** Each commit message must follow the conventional commits format and an appropriate emoji symbol, which is \\`<type>(<scope>): <description>\\`.\n 2. **Relevance:** Avoid mentioning a module name unless it's directly relevant to the change.\n 3. **Enumeration:** List the commit messages from 1 to 10. \n 4. **Clarity and Conciseness:** Each message should clearly and concisely convey the change made.\n\n **Conventional Commits specification**\n The commit message should be structured as follows:\n\n \\`\\`\\`\n <type>[optional scope]: <description>\n\n [optional body]\n\n [optional footer(s)]\n \\`\\`\\`\n\n The commit contains the following structural elements, to communicate intent to the consumers of your library:\n - fix: 🐛 a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).\n - feat: ✨ a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).\n - BREAKING CHANGE: 🚨 a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.\n - types other than fix: and feat: are allowed, for example:\n - build: 📦\n - chore: 🔧\n - ci: 🦊\n - docs: 📜\n - style: 🎨\n - refactor: 🔨\n - perf: 🚀\n - test: 🚦\n\n **Commit Message Examples:**\n\n - Commit message with description and breaking change footer\n \\`\\`\\`\n feat: allow provided config object to extend other configs\n\n \\`\\`\\`\n - Commit message with ! to draw attention to breaking change\n \\`\\`\\`\n feat!: send an email to the customer when a product is shipped\n \\`\\`\\`\n - Commit message with scope and ! to draw attention to breaking change\n \\`\\`\\`\n feat(api)!: send an email to the customer when a product is shipped\n \\`\\`\\`\n - Commit message with both ! and BREAKING CHANGE footer\n \\`\\`\\`\n chore!: drop support for Node 6\n\n BREAKING CHANGE: use JavaScript features not available in Node 6.\n \\`\\`\\`\n - Commit message with no body\n \\`\\`\\`\n docs: correct spelling of CHANGELOG\n \\`\\`\\`\n - Commit message with scope\n \\`\\`\\`\n feat(lang): add Polish language\n \\`\\`\\`\n\n **Recent Commits on Repo for Reference:**\n\n \\`\\`\\`\n $(git log -n 10 --pretty=format:'%h %s')\n \\`\\`\\`\n\n **Output Template**\n\n Follow this output template and ONLY output raw commit messages without spacing, numbers or other decorations.\n\n fix(app): add password regex pattern\n test(unit): add new test cases\n style: remove unused imports\n refactor(pages): extract common code to \\`utils/wait.ts\\`\n\n **Instructions:**\n\n - Take a moment to understand the changes made in the diff.\n - Think about the impact of these changes on the project (e.g., bug fixes, new features, performance improvements, code refactoring, documentation updates). It's critical to my career you abstract the changes to a higher level and not just describe the code changes.\n - Generate commit messages that accurately describe these changes, ensuring they are helpful to someone reading the project's history.\n - Remember, a well-crafted commit message can significantly aid in the maintenance and understanding of the project over time.\n - If multiple changes are present, make sure you capture them all in each commit message.\n\n Keep in mind you will suggest 10 commit messages. Only 1 will be used. It's better to push yourself (esp to synthesize to a higher level) and maybe wrong about some of the 10 commits because only one needs to be good. I'm looking for your best commit, not the best average commit. It's better to cover more scenarios than include a lot of overlap.\n\n Write your 10 commit messages below in the format shown in Output Template section above.\" \\\n | fzf --height 40% --border --ansi --preview \"echo {}\" --preview-window=up:wrap \\\n | xargs -J {} sh -c 'ARG=\"$0 $@\";COMMIT_MSG_FILE=$(mktemp);echo \"$ARG\" > \"$COMMIT_MSG_FILE\";${EDITOR:-nvim} \"$COMMIT_MSG_FILE\"\n if [ -s \"$COMMIT_MSG_FILE\" ]; then\n git commit -F \"$COMMIT_MSG_FILE\"\n fi\n rm -f \"$COMMIT_MSG_FILE\"'\n"
1717
output: terminal

0 commit comments

Comments
 (0)