3 ms·

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 impo

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/ https://www.conventionalcommits.org/en/v1.0.0/

wdroz 2y ago
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 https://github.com/compilerla/conventional-pre-commit
mihaaly 2y ago
> 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).
- lloydatkinson 2y ago
  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.
  - mihaaly 2y ago
    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.
    - Izkata 2y ago
      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.
      - lloydatkinson 2y ago
        > 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.
      - shepherdjerred 2y ago
        You can skip pre-commit hooks with the --no-verify flag https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---no-verify https://git-scm.com/docs/git-commit#Documentation/git-commit...
  - keybored 2y ago
    > 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.
    - lloydatkinson 2y ago
- sloowm 2y ago
  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.
lolinder 2y ago
> 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?

wdroz 2y ago

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 https://github.com/compilerla/conventional-pre-commit

mihaaly 2y ago

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

lloydatkinson 2y ago
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.
- mihaaly 2y ago
  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.
  - Izkata 2y ago
    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.
    - lloydatkinson 2y ago
      > 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.
    - shepherdjerred 2y ago
      You can skip pre-commit hooks with the --no-verify flag https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---no-verify https://git-scm.com/docs/git-commit#Documentation/git-commit...
- keybored 2y ago
  > 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.
  - lloydatkinson 2y ago
sloowm 2y ago
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.

lolinder 2y ago

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