Hacker News Reader

Comment by the_duke | Hacker News Reader

What other comments are missing is that git-cliff is based on the conventional commits [1] spec.

If you follow this properly the commits will already have important metadata for presentation in a changelog.

Also keep in mind that the auto-generated changelog should always be augmented and filtered manually before the final release.

But the combination of git-cliff and conventional commits can save a lot of time for the initial draft.

It does require discipline in using conventional commits properly.

[1] https://www.conventionalcommits.org/en/v1.0.0/

View on HN

> 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).

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.

> 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.

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/

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.

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

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

You can use conventional pre-commit[0] to validate that commit messages follow the convention and use only the types that the team agreed upon.

This still requires discipline to choose the "right" type and scope.

[0] -- https://github.com/compilerla/conventional-pre-commit

> But the combination of git-cliff and conventional commits can save a lot of time for the initial draft.

Does it though? What would happen if we instead directed our discipline into updating the changelog manually on each PR?

Does having git cliff as the middleman provide much value if I have to enforce highly specific logging practices in the PR anyway?

Reply on news.ycombinator.com