feat(git): add generate_release_notes operation#11
Conversation
jinzhongjia
commented
Aug 1, 2025
jinzhongjia
commented
- implement generate_release_notes for release notes generation between tags
- support markdown, plain, and json output formats with Conventional Commits categorization
- update documentation and usage examples for the new operation
- expose generate_release_notes in git tool API and git_read schema
- implement generate_release_notes for release notes generation between tags - support markdown, plain, and json output formats with Conventional Commits categorization - update documentation and usage examples for the new operation - expose generate_release_notes in git tool API and git_read schema
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @jinzhongjia, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
I've implemented a new generate_release_notes operation for the git_read tool. This feature allows users to automatically create structured release notes between specified Git tags, supporting various output formats like Markdown, plain text, and JSON, and intelligently categorizing commits based on Conventional Commits.
Highlights
- New Git Operation: Introduced generate_release_notes to the @{git_read} tool, enabling automated generation of release notes from Git history.
- Flexible Tagging: The operation can automatically detect the latest and second-latest tags or accept specific from_tag and to_tag arguments for precise range selection.
- Multiple Output Formats: Release notes can be generated in Markdown (default), plain text, or JSON formats to suit different consumption needs.
- Conventional Commits Support: Commits are automatically categorized into 'Features,' 'Bug Fixes,' and 'Other Changes' based on Conventional Commits specification, providing a clear and organized summary.
- API and Documentation Updates: The new operation is fully integrated into the git_tool API and extensively documented in both the README.md and the plugin's help file, including usage examples.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces a new generate_release_notes operation, which is a great addition. The implementation is well-structured, and the feature is well-documented across the README and help files. I've identified a critical security vulnerability and a couple of other areas for improvement in the core implementation. My review includes detailed suggestions to address these points, enhancing security and ensuring deterministic output.
- sort contributors in descending order of commit count in generated release notes - use alphabetical order as a tiebreaker for contributors with equal commit counts
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a generate_release_notes operation, which is a great addition. The implementation is mostly solid, with good handling of different output formats and Conventional Commits. I've found a critical syntax error and a high-severity issue related to commit message parsing that could lead to incorrect release notes. I've also included some suggestions to improve code maintainability and conciseness. Once these issues are addressed, this will be a robust feature.
- adjust whitespace and indentation for consistency in generate_release_notes - split long lines and clarify string concatenation for error messages - fix minor formatting issues in contributors and commit grouping sections - update git_read to use multiline assignment for generate_release_notes call
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a new generate_release_notes operation, which is a great addition. The implementation is solid, with good handling of different output formats and edge cases. The documentation has also been updated accordingly. I've found a couple of areas for improvement: one is a misleading API usage example in the README that should be corrected, and the other is a suggestion to refactor string building logic for better performance and readability in the core function. Overall, great work on this feature.
- use ASCII unit separator for robust commit field splitting - escape commit range argument to prevent shell injection - update parsing logic to handle new separator and improve reliability
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
- replace string concatenation with table accumulation and table.concat for markdown and plain formats - improve performance and readability of release notes generation - ensure consistent formatting across different output formats
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable generate_release_notes feature. The implementation is solid, with good error handling and logic for detecting tags and parsing commits. The documentation has been updated accordingly.
My review focuses on improving the implementation's maintainability by addressing code duplication in the Lua code. I've also pointed out a small redundancy in the README documentation to improve clarity for users.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a new generate_release_notes operation, which is a great addition. The implementation is solid, providing markdown, plain, and JSON output formats with Conventional Commits categorization. The documentation has also been updated accordingly.
I've found a few areas for improvement:
- There's a bug in how Conventional Commit types are parsed, which fails for commits with scopes.
- The categorization logic accepts non-standard commit types (
feature,bugfix). - The
README.mdcontains a redundant code example.
I've left specific comments with suggestions to address these points. Overall, this is a well-executed feature.
| local others = {} | ||
|
|
||
| for _, commit in ipairs(commits) do | ||
| local type_match = commit.subject:match("^(%w+):") |
There was a problem hiding this comment.
The current regex ^(%w+): for parsing the Conventional Commit type does not handle commits with scopes (e.g., feat(parser): ...). This will cause such commits to be miscategorized under 'Other Changes'. To correctly extract the type, the regex should be changed to ^(%w+) to capture the type part before any optional scope.
local type_match = commit.subject:match("^(%w+)")
- update regex to support Conventional Commits with scopes - ensure features are correctly categorized when scope is present
- match only "feat" and "fix" types for features and fixes - exclude "feature" and "bugfix" aliases from type parsing
|
/gemini review |
|
/gemini summary |
There was a problem hiding this comment.
Code Review
The pull request introduces a new generate_release_notes operation to the git tool, enabling release notes generation between tags with support for markdown, plain, and JSON output formats. The changes include updates to documentation and usage examples, as well as exposing the new operation in the git tool API and git_read schema. I've provided feedback to improve the code's robustness and readability.
Summary of ChangesI've implemented a new Highlights
Changelog
Activity
|
- check for empty or failed shell escaping of tag range - return error messages if escaping fails before running git log - improve robustness of release notes generation with invalid tags
|
/gemini summary |
Summary of ChangesI've implemented a new Highlights
Changelog
Activity
|
- update commit message examples to use scoped Conventional Commits - clarify release notes generation usage in README - enhance feature list to highlight scope support, contributor sorting, and security improvements
1 participant
