-
Notifications
You must be signed in to change notification settings - Fork 4.1k
feat: add support for generating commit message #5828
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Your cubic subscription is currently inactive. Please reactivate your subscription to receive AI reviews and use cubic. |
👷 Deploy request for continuedev pending review.Visit the deploys page to approve it
|
|
@lkk214 I like this a lot! If we add this in IntelliJ, do you think we could add it in VS Code as well? It can be bothersome when there isn't feature parity. Otherwise, I like what you did with the UI and whenever you've got the code in a closer spot I'd be happy to review |
|
This is an incredible feature! I've been looking forward to it for quite some time. Will it be supported in VS Code? |
|
@lkk214 I have a small suggestion: would it be possible to provide a method that allows users to specify the submission format? |
# Conflicts: # core/core.ts # core/protocol/core.ts
|
Hi @sestinj, this PR is now ready for review. |
|
|
| signal, | ||
| }: GenerateCommitMessageParams): AsyncGenerator<string> { | ||
| if (!diff) { | ||
| diff = await ide.getDiff(includeUnstaged ?? false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function uses an optional chaining that could result in undefined being passed to getDiff(). The IDE interface requires a boolean parameter for getDiff(), but this line allows undefined to be passed when includeUnstaged is undefined. This will cause a runtime type error. The code should ensure a boolean default value is always provided, like in the original code that used params?.includeUnstaged ?? false.
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
| */ | ||
| object ContinueIcons { | ||
|
|
||
| val CONTINUE = icon("/icons/continue.svg") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The icon path '/icons/continue.svg' references a resource that does not exist in the project structure. Icons must be placed in the src/main/resources directory of the plugin. This will cause IconLoader.getIcon() to return null or throw an exception at runtime, leading to missing icons in the UI. Place the SVG file in the correct resources directory and ensure the path matches the actual file location.
React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)
|
😱 Found 2 issues. Time to roll up your sleeves! 😱 |
sestinj
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything here looks great. I don't have an requests as far as the quality of the code (I appreciate the nice little refactorings, e.g. with the icons), but I did find one small bug when testing locally.
Right now, if you are using a thinking model, the thinking will be included in the commit message. You can reproduce this by using the reasoning option: https://docs.continue.dev/reference#models.
There are two potential options here:
- just override the completionOptions to disable thinking (this would be reasonable)
- make a small utility method (so it can be reused here) that strips thinking from the output
|
Yes, I do need to consider the thinking model... For handling this, compared to creating a utility method to strip out the thinking for reuse in different places, I prefer disabling thinking directly in the concrete implementation of BaseLLM. If we don't need it, perhaps we shouldn't let it be returned from BaseLLM in the first place—this approach seems more reasonable to me. |
# Conflicts: # core/commands/slash/commit.ts # core/core.ts
sestinj
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this approach
# Conflicts: # core/commands/slash/built-in-legacy/commit.ts
# Conflicts: # extensions/intellij/src/main/kotlin/com/github/continuedev/continueintellijextension/autocomplete/AutocompleteSpinnerWidgetFactory.kt # extensions/intellij/src/main/kotlin/com/github/continuedev/continueintellijextension/continue/IntelliJIde.kt # extensions/intellij/src/main/kotlin/com/github/continuedev/continueintellijextension/editor/InlineEditPanel.kt
|
@sestinj Merge conflicts keep popping up—any ETA on merging this? |
|
will merge today if can get the tests to pass |
# Conflicts: # core/core.ts
|
it seems like there are legitimate failing tests on this and it's been a while that this PR has been open. While I think it is a great change, I'm quite worried given how long it has taken to merge that it's going to become a large maintenance burden. I'm going to close the PR and would love to start a fresh one perhaps if you think there is a better approach we can take, but since I can't merge with failing tests it doesn't feel like this one has been making enough progress. Open to other ideas as usual! |

Description
Generate commit messages based on selected changes in the workflow UI.
config.modelsByRole.chatas the model list sourceScreenshots