Feedback: general

[lppedd]

Feel free to write down whatever you want regarding the plugin, good and bad things you noticed using it, things you would like to see implemented or enhanced.

[Gerrit-K]

First of all thanks for all the effort in making this an even better plugin!

One suggestion I would like to propose: autosuggested scopes based on git history.

Background/details:
Our team started to use the conventional commit structure, but it's currently more of a guideline than a strict schema. In particular, we don't have fixed scopes, but everyone has a gist (and probably a personal opinion) on what to include as a scope in the parentheses. E.g. some commits reference a sub-path of the (mono)repo, like chore(python-app): something, some others might reference a (potentially cross-path) feature, like feat(feature-A): implemented new feature. For the reoccurring scopes (like in this case python-app) it would be useful to us if scopes would be autocompleted with all scopes that are already present in the git history.

I'd love to hear feedback on this idea. Cheers!

[lppedd]

@Gerrit-K Hi! Thanks a lot for the feedback 😄

One suggestion I would like to propose: autosuggested scopes based on git history.
...
For the reoccurring scopes (like in this case python-app) it would be useful to us if scopes would be autocompleted with all scopes that are already present in the git history.

This is similar to what I already do with the subject token.
If you look under the Providers settings you will notice the default provider is called Default - VCS.
This is because the subjects are extracted from the most-recent commit messages.
This isn't always accurate and I still have to understand how the Platform updates those "recent messages", so months ago I arrived at the conclusion that this kinda feature you proposed should be released as an Extension Provider (another plugin) which will look through the real VCS history.

This is absolutely a good idea that I will consider developing in the next month. I'm a bit busy now trying to create a real language (with an AST) for conventional commits.

[lppedd]

@Gerrit-K just a question: should the history-proposed scopes be extracted based on the inputted type, or would you like to see all of them anyway?

[Gerrit-K]

@lppedd thanks for the swift reply!

This is similar to what I already do with the subject token.

Yes, exactly that, but for scopes. Totally forgot about checking the settings 🙈 Seeing this now, I actually don't know if we really need the full history or if the recent history would suffice too. Would have to experiment with that. If it makes things easier, feel free to start with the latter, if you like.

should the history-proposed scopes be extracted based on the inputted type, or would you like to see all of them anyway?

For us I think it would make more sense to see all, because we usually perform different types on the same scope (e.g. fix(python-app), chore(python-app), feat(feature), refactor(feature)). But that might be just an opinion based on our way of committing, of course 😉

[lppedd]

@Gerrit-K the development for 0.17.0 is finished. It will be published tomorrow I think.

For whoever is reading, keep the suggestions coming 😄

[cn-src]

The type of non-English characters cannot be customized.

{
    "types": {
        "重构": {
            "description": "Changes which neither fix a bug nor add a feature"
        }
    }
}

[lppedd]

@cn-src oh wait, I don't understand 😅 Do you mean you cannot use non-ASCII characters in the custom JSON file?

[lppedd]

@cn-src yeah now I got it. The JSON Schema allows only a-zA-Z0-9-. You're right.

[ymind]

The type of non-English characters cannot be customized.

{
    "types": {
        "重构": {
            "description": "Changes which neither fix a bug nor add a feature"
        }
    }
}

建议保持简短的且标准的英文表述，后期处理时也更加方便、有规范。
It is recommended to keep a short and standard expression by English, it will be more convenient and standardized in post-processing.

可以参考我整理的常见提交类型:
You can refer to the common commit types here:
https://semantic-gitlog.github.io/semantic-gitlog/#/en-us/fundamentals/commit-types

[rluvaton]

Awesome plugin, one thing that prevents me from using it is the lack of GUI, I think it would be awesome if you would add something like VS Code - Conventional Commits Plugin

[agileago]

@lppedd maybe allow more other non-ASCII characters is better. i want to use chinese to show the commit type message

[agileago]

The type of non-English characters cannot be customized.

{
    "types": {
        "重构": {
            "description": "Changes which neither fix a bug nor add a feature"
        }
    }
}

建议保持简短的且标准的英文表述，后期处理时也更加方便、有规范。
It is recommended to keep a short and standard expression by English, it will be more convenient and standardized in post-processing.

可以参考我整理的常见提交类型:
You can refer to the common commit types here:
https://semantic-gitlog.github.io/semantic-gitlog/#/en-us/fundamentals/commit-types

建议是好的，但团队里面确实是有中文需求的，规范都是人定的，没必要说一定要用英文

[lppedd]

@ymind @agileago I think the request is fair, since this plugin does not try to enforce specific rules (an inspection might be a better alternative). I have some free time now so I'll get back to this.

[lppedd]

@rluvaton I'm not familiar with that plugin. Could you shortly describe what kind of UI you'd like to have?
I mean, you can complete the commit message in template mode.

[agileago]

@lppedd Thanks for your work. very grateful

[lppedd]

@agileago @cn-src hi guys, as you know 0.18.0 is out.
I'd like to get some feedback: are you able to correctly use custom commit tokens with chinese characters? Everything is still displayed correctly?

[patrek]

Autocomplete is very nice if you are familiar with conventional commits.
But, a dialog showing the differents options and sections to fill would be a nice addition for newcomers and people with less memory. Something like : https://plugins.jetbrains.com/plugin/9861-git-commit-template

[lppedd]

@patrek good suggestion! This could be something that gets proposed at installation time. Like "Do you prefer doing this or that?".
I will build the dialog, and after the install-time choice, which is more difficult (need to join it with the What's New dialog somehow).

[patrek]

@patrek good suggestion! This could be something that gets proposed at installation time. Like "Do you prefer doing this or that?".
I will build the dialog, and after the install-time choice, which is more difficult (need to join it with the What's New dialog somehow).

Could also be as simple as adding an icon to the stock commit dialog, with an option to remove it in the settings page. One would press the button when necessary.

[gaeljw]

Hi, first I want to say really good work on this plugin 👍
I was wondering how to integrate emojis in the commit message depending on the type.

Until now I was using a CLI tool to commit and when selecting the type feat for instance, it adds automatically an emoji (defined via config) so that the commit message looks something like feat: 🚀 my commit msg.

It's really just cosmetic but wondering if it could easily be defined via the types schema as an optional attribute maybe?

[lppedd]

@gaeljw hi!
So the emoji associated with the commit type is part of the short description?

If it's so, unfortunately you cannot do anything with the custom file, and this isn't accounted in code too.

What can be done is:

• propose emojis in completion, so that you can pick it by yourself
• let you associate an emoji to a commit type, and prefix automatically the short description based on the commit type
• let you associate an emoji to a commit type, and insert the emoji as soon as you type the separator ':' (but then how will it work in template mode)
• introduce a mechanism to listen to token insertion by addon plugins, which means I can modify what this plugin insert when picking a completion item

What do you think is more appropriate?
And also, do you think this enhancement really belongs to Conventional Commit or could be introduced with a completely separate plugin?

Edit: also another option that can work in tandem with emoji in completion, an inspection with a quick fix that warns you in case you forgot the associated emoji.

Edit 2: need to verify if it's possible, but what about a commit hook that adds the emoji before committing, if it's not present? You could type the message without emoji and don't worry about it.

[gaeljw]

So the emoji associated with the commit type is part of the short description?

Yes

What can be done is:

• propose emojis in completion, so that you can pick it by yourself
• let you associate an emoji to a commit type, and prefix automatically the short description based on the commit type
• let you associate an emoji to a commit type, and insert the emoji as soon as you type the separator ':' (but then how will it work in template mode)
• introduce a mechanism to listen to token insertion by addon plugins, which means I can modify what this plugin insert when picking a completion item

What do you think is more appropriate?

What I would expect is more option 2, not sure how it interacts with the existing features of the plugin though.

Option 1 could be an intermediate solution but only if autocompletion reminds the meaning of emojis (the association type-emoji).

Addon plugins feels overkill to me.

And also, do you think this enhancement really belongs to Conventional Commit or could be introduced with a completely separate plugin?

Good question. It's really not something mandatory or even everyone will want, thus not sure.. 🤷‍♂️

Edit 2: need to verify if it's possible, but what about a commit hook that adds the emoji before committing, if it's not present? You could type the message without emoji and don't worry about it.

I guess it's a matter of preferences but not fan of using commit hooks in general, and even more for this use case.

[lppedd]

@gaeljw

What I would expect is more option 2

That's fair, however there is something to clarify.
Let's say we have

feat(my-scope): <caret>

When you invoke the completion popup at caret positon, I can prefix the completion items with the emoji.
But what if you just start typing? What should the plugin do in this case in your vision?

[gaeljw]

@lppedd

I hadn't actually play enough with the plugin yet and didn't realize the : separator was not always automatically added.
If the : was always automatically added, I would have expected the emoji to be added at the same time.

Anyway, I just realised that IntelliJ doesn't show emoji nicely in the commit dialog :(

I guess we can postpone this potential feature to later! I'll maybe get used to no emoji 😄

[lppedd]

@gaeljw yeah, especially if you're on Windows, there are major issues with emojis, which are rendered as monochrome symbols.
E.g. https://youtrack.jetbrains.com/issue/JBR-2917

But leaving that aside, it seems you'd want to go with

let you associate an emoji to a commit type, and insert the emoji as soon as you type the separator ':'

And have you considered the inspection option?

[gaeljw]

@lppedd Linux but still not good looking emoji 😅

And have you considered the inspection option?

Not sure what inspection means in this context TBH.

(BTW maybe we should move this discussion to the Github Discussions to not pollute too much this thread?)

[lppedd]

I've implemented highlighting for the header part of the message (type, scope, breaking change, subject).
What do you think? Should I expand that also to footers?

[AVROTROS-developers]

An checkbox to add [skip ci] to the commit message (like : https://plugins.jetbrains.com/plugin/9861-git-commit-template has) or an option to configure whether the value in a custom footer is required or not (so we can make a skip ci footer that doesn't require a value).

[lppedd]

@AVROTROS-developers where would you like to have this checkbox? As a general settings? Or in the commit builder dialog?

[AVROTROS-developers]

I think in the dialog would be best, so you can enable it when committing something that should not trigger the CI.

[maxbebaasuro]

This plugin is really cool!
We are currently introducing conventional commits using commitlint.
It would be great if you could add an option do disable providers. As we have a lot of wrong stuff in vcs history and want to enforce that only types from commitlint can be used.

[lppedd]

Hi @maxbebaasuro! In the meantime, try disabling it using the registry key com.github.lppedd.cc.providers.vcs.

idea-conventional-commit/src/main/kotlin/com/github/lppedd/cc/CC.kt

Line 28 in a6fcdae

const val VcsEnabled: String = "com.github.lppedd.cc.providers.vcs"

[BenceSzalai]

Hey! I'd love to see support for comma separated scopes added. See details here: conventional-changelog/commitlint#901

[davinkevin]

Really good plugin!

I feel how good it is now, after update to 2024.1 and not being able to use it anymore