How to add a Conventional commit specification before committing

[oldqin97]

I used custome command to create a Conventional commit option, but I need to create an input for the information myself, which is very bloated. I want to let this Conventional commit option box go directly to lazygit's original commit input box after selecting it, and add feat(test.js): to the front of the subject, and I will add detailed information later

[stefanhaller]

I'm strongly opposed to adding conventional commits functionality to lazygit. Conventional commits is a misguided attempt at encouraging better commits; I think it does more harm than good. I don't want to encourage its use by adding it to lazygit.

If you need to use conventional commits because your workplace demands it, then custom commands are the way to go (instead of generating the prompts yourself as shown in your screenshot you can also run one of the many command line tools that prompt you in the console). If it's your own choice to use them, consider just not doing it.

[ChrisMcD1]

To add a differing opinion, I am a fan of conventional commits. I find it useful to indicate to future people "This should just be a clean refactor, if you find a behavioral change, I did not intend it".

But I am also not seeing any utility in a lazygit integration. The prefixes are all very short, so it's pretty easy to type. Such as feat(cli): Added support for new thing. If I'm imagining a perfect input form that does this, I would still need to type fe<tab>cli<tab>Title. fe needed to differentiate from fix, assuming some sort of fuzzy matching. This saves only 3 keystrokes from your message, which if it is a good message, probably has many more than 3 keystrokes.

Do you have some other flow that I'm not imagining that means you're seeing substantial gains from your custom command?

[itpropro]

This would be a great addition to lazygit. Conventional commit have become the defacto standard for good commit messages not only in most open source, but also commercial projects.
Beside it's broad acceptance and adoption, there is also a lot of tooling available to generate changelogs, bump versions, create stats, etc..
Therefore native support in some way would be something that the vast majority of people interacting with git would benefit from.

[stefanhaller]

I can only repeat what I said above:

Conventional commits is a misguided attempt at encouraging better commits; I think it does more harm than good. I don't want to encourage its use by adding it to lazygit.

Now, I didn't explain why I think so. The main reasons for this opinion are:

• it encourages making commits that are too big (at least for the 'feat' category). If one of the main purposes of conventional commits is that you can generate release notes from them, then it follows that most feature PRs will have one commit that adds the feature (because you will want to have one line or bullet point per feature in the release notes). This only makes sense for really simple features; more complex features will have many, many commits that contribute to adding the feature, unless people squash all their non-refactoring changes into one. And this is really bad and should be discouraged, but conventional commits encourages it.
• it fools people into believing that they are making good commit messages just because they are using conventional commits. There are so many other aspects to a good commit message, e.g.
  • describing why you are making a change. Many people only describe what they are changing, which is much less important because it can be seen from the diff.
  • mentioning an exact reproduction recipe for a bug that is being fixed
  • mentioning possible alternative implementation approaches that have been considered but rejected (and why)
  • and many more.
    Are these things any more likely to happen when people aren't using conventional commits? Maybe not, but with conventional commits people think they are done providing a high quality commit message once they have picked the right prefix.

I do realize that I'm probably fighting an uphill battle though.

I find it useful to indicate to future people "This should just be a clean refactor, if you find a behavioral change, I did not intend it".

This doesn't need emphasizing; in any sane commit history it should be a matter of course.

[itpropro]

Thanks for your explanation, I think we agree in general that conventional commits do not decrease the quality of commit messages, in the worst case, they would stay the same with some additional metadata information.
I don't think that conventional commits would encourage to make "bigger" commits, I have not seen that in any project and it cannot really be said about most OSS projects that use conventional commits, but I understand the concern.
The thing that I have seen most often with conventional commits, especially if you have predefined scopes is that people start thinking about what they actually did.
They don't replace proper guidelines, but they can support a lot with existing guidelines and workflows that people already use. Conventional commits are just a tool and it's up to the teams or maintainers how they use the convention and how they integrate them into their processes and guardrails.

To not go off topic too much, I think they would be a valuable addition to lazygit, especially as they are so broadly adopted throughout the whole open source ecosystem.
Lazygit should support developers and teams with their workflows, so making the assumption that people would not benefit from conventional commits just because they can be misused, despite many teams using them successfully to support their workflows is not helping the users of lazygit, it is just forcing them to integrate other tooling for a comparatively uncomplex functionality.

[ChrisMcD1]

@itpropro I hear your points about the benefits of conventional commits, but I'm still not hearing a product oriented description of what is being asked to be introduced.

What could Lazygit add that would help a user of conventional commits? If @stefanhaller were to wake up tomorrow and have a fire burning inside of him to help maintain a deep integration with conventional commits (emphasis on if 😆 ), what would that feature look like?

I'm still hung up on my original point:

But I am also not seeing any utility in a lazygit integration. The prefixes are all very short, so it's pretty easy to type.

[itpropro]

@ChrisMcD1 I would see the following features as part of optional conventional commit support

• Config key to enable/disable support in the config (default off)
• Easy selection of conventional commit type (feat, chore, fix, etc.) with auto completion during typing (maybe sorted by most frequently/recently used)
• Selection of an optional scope
• Being able to define a list of scopes in the users/repo config
• Prepend the commit title with the selected "{type}({scope}): " prefix
• Support for standard footers to be able to use semver with the commits (BREAKING, BREAKING CHANGE, closes, etc.)
• Support for widely used ! syntax to mark breaking changes (fix!: Fixed foo in bar to make foo better)

The flow would basically be to select a type and scope, write a descriptive title, if needed write a description and optionally append a footer.
Integrating it natively in lazyvim instead of manually typing things like "fix(order-api): Fixed order struct test field to prevent overflow" would help a lot with consistency and speed when working with conventional commits. People not only make typos in the types or scopes, they also make up scopes or types sometime, forget the correct syntax or forget to mention that it is actually a breaking change or closes an open issue.
Most of these issues can be avoided or at least be made much more unlikely to occur.

[JordanllHarper]

The only way I would like this implemented is an autocomplete behaviour where you type "fe" for feature commit and get some mandatory spots to fill in. Tabbing through menus doesn't sound good and could conflict with #4627 .