Hacker News Reader

Comment by mihaaly | Hacker News Reader

> If you follow this properly

There it goes! One more thing to do precisely and not only at dedicated time but continuously on top of all other things to do precisely already inherently around completing a task. Everyone all the time think about the state of changelog communication in addition, and do it well, phrase it for changelog purposes, format it for that as well. While working on changelog on the end will need additional work still.

In some simple situation it may have merit though, I admit. Seems like additional trouble (both workload and source of mistakes) in a medium to large team.

Except if the developers are well programmed robots themselves, of course, those do not fail (or easy to throw out and replace if they do).

View on HN

The other option is someone scouring through the mess of commits to find out what should be in the changelog or you have to update the changelog with each commit to the main branch. Which brings you back to the extra step on top of things you need to do.

So this is a way to reduce overhead, you need to write a commit message anyway so why not reuse that effort.

"Simple" projects like curl use their commit messages for the changelog.

If a team of devs is incapable of writing good commits with simple prefixes then that's a strong case for adding git hooks that reject commits without the prefix.

Before someone starts getting their pants in a twist at this idea, you can configure a solution such that commits to branches don't need a conventional commit format, but that the commit that merges a PR into master must have conventional commit format.

In an idealized and simplistic (imaginary) world you are completely right, but here you missed the point quite a bit:

People make mistakes! Everyone! Already.

More things to watch for and take care of, with more people: more mistakes.

Too much mistakes - that we already have without more aspects - negate the advantages of the idealized intended outcome.

People working with other people in everyday situations could understand that.

Forget mistakes, such a commit hook would prevent me from making small iterative commits. I'd just disable that hook within the first few days.

> Before someone starts getting their pants in a twist at this idea, you can configure a solution such that commits to branches don't need a conventional commit format, but that the commit that merges a PR into master must have conventional commit format.

You can skip pre-commit hooks with the --no-verify flag

https://git-scm.com/docs/git-commit#Documentation/git-commit...

Not can, must. You cannot enforce this for local development since git(1) doesn’t allow project-wide hooks for security reasons.

I don't know where you're getting this but there are in fact many tools for local commit hooks https://typicode.github.io/husky/

Reply on news.ycombinator.com