To be or not to be - git pre-commit hooks

[chinmaykunkikar]

The discussion was started between me and @krishnaacharyaa after seeing a couple of bad commit messages in a merge request.

So far, this is the discussion about introducing some kind of mechanism to avoid bad commit messages.

@chinmaykunkikar

Also, I request you to follow the commit message format mentioned in the contribution guidelines.
"Changes Updated", and "Changes needed" confuses others, while it doesn't tell me or Krishna anything about the commit.
It's possible that one might not know what to write as the message for the changes. In such cases, mention the PR id and mention some keywords from your last conversation about the requested changes.

@krishnaacharyaa

@chinmaykunkikar, thanks for bringing that up. I was actually considering to add some constraints before making commits, didn't get any major leads, Do you know or tried? If such thing is possible. That would actually be really great for us because people unknowingly forget the format and there's no way out.

@chinmaykunkikar

@krishnaacharyaa It's possible using husky and pre-commit hooks. But, let's not do that. Let's not make it a pain in the bum for the devs who have worked on something and want to commit their work.
We can explore some other solutions for what you're mentioning.

@krishnaacharyaa

@chinmaykunkikar, just a confirmation, how does it causes trouble to the devs? I meant when someone tries to commit which doesn't obey the predefined regex we give some friendly error message saying "Use this regex for the commit message". If we can get this done using the husky, then I think we are good. Happy to consider your recommendations :)

[chinmaykunkikar]

@chinmaykunkikar, just a confirmation, how does it causes trouble to the devs? I meant when someone tries to commit which doesn't obey the predefined regex we give some friendly error message saying "Use this regex for the commit message". If we can get this done using the husky, then I think we are good. Happy to consider your recommendations :)

I understand what you are trying to do here. I love a clean commit history where every commit has something useful related to a bug, feature, or a refactor.
But, I also believe the commit messages need not have such rigid structuring. Every commit need not be meaningful. A perfect and clean commit history is a myth in projects (like wanderlust) where there are many contributors and collaborators.
Some of my arguments are -

• Everyone has different style of coding. Some people like to keep committing small changes to a feature branch and squash these small commits at the end with a proper message. The pre-commit hooks directly attack such devs.
• Pre-commit hooks will make everyone do the process of committing at least twice because the first commit process was failed.
• These hooks are also fairly easy to disable. So someone can still commit bad messages and actually push them to the server.

But, there are always middlegrounds. Like you're saying, we can setup a hook that runs a regex to detect feat, bug, etc. without being rigid about it. For example, I should be able to use [fix] fix bug 1337 or fix - fix bug 1337 without the hook pestering me.

Later, we can also have a special wip suffix that will be blocked by a pre-push hook. The dev is required to squash changes and change it to some other tag before pushing it. There will be a few edge cases for this to work without it being a problem.

[krishnaacharyaa]

@chinmaykunkikar, sorry I almost forgot this, I'll do some R&D and get back to you on this :)

[krishnaacharyaa]

@kuldeepjambhulkar @shmbajaj feel free to join party ;)

[bajajcodes]

Hey @krishnaacharyaa I believe https://www.conventionalcommits.org/en/v1.0.0/ will work, but
doubt is commit linting or pre-commit hooks are really important without automatic workflows?

How will you explain the benefit except the obvious, maintain standard and structure?

I believe we should wait and focus on automatic workflow then push git pre commit hooks.

cc: @chinmaykunkikar

[krishnaacharyaa]

@shmbajaj soo... Lets do the automatic workflow then .... As soon as we complete the test cases, we'll set up workflow and make sure that test cases passes and has minimum code coverage before being pushed, I assume this is the workflow you are talking about, kindly correct me if I am wrong,

How does it sound @chinmaykunkikar ?

[bajajcodes]

Yes @krishnaacharyaa I am talking about the same.