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.