3 ms·

> You have to care about this for every final commit that lands in the project Same as having a standard coding style, you should have a standard commit messag

> You have to care about this for every final commit that lands in the project Same as having a standard coding style, you should have a standard commit message style that you do care about for every commit in the project. A mish-mash of variable quality and variable formatted commits more than subjectively looks bad - it reduces the signal-to-noise of the commit messages. As for the `feat(scope):` in the subject line, it's a very succinct way to communicate the type of the change. Don't make me the read the whole commit to figure out if this was a feature or bug fix, or only affected the build. > Just serve a changelog Sure. But I want the changelog to list features first, then bug fixes, etc. How do I do that automatically with only the git log w/o some sort of standardized tagging of the commits?

keybored 2y ago
> Same as having a standard coding style, you should have a standard commit message style that you do care about for every commit in the project. A mish-mash of variable quality and variable formatted commits more than subjectively looks bad - it reduces the signal-to-noise of the commit messages. I already personally use a standard commit message style.[1] And that standard is about how to structure the prose, not about using any kind of structured markup (outside the trailers section). > As for the `feat(scope):` in the subject line, it's a very succinct way to communicate the type of the change. Don't make me the read the whole commit to figure out if this was a feature or bug fix, or only affected the build. Verbs already serve that purpose most of the time. Then you get redundant lines like `feat: add OAuth 2.0 login`. > Sure. But I want the changelog to list features first, then bug fixes, etc. How do I do that automatically with only the git log w/o some sort of standardized tagging of the commits? If you have such a high volume of commits (that users would care about) that you have have distribute tagging of all commits to all contributors,[2] you can use the trailers section.[3] [1] I don’t expect anyone else to at work. In one free-time project people use the same style, with one exception (against my personal taste). [2] And if you need such a detailed changelog, let alone a fully automatically written one [3] https://news.ycombinator.com/item?id=40820213 https://news.ycombinator.com/item?id=40820213

keybored 2y ago

> Same as having a standard coding style, you should have a standard commit message style that you do care about for every commit in the project. A mish-mash of variable quality and variable formatted commits more than subjectively looks bad - it reduces the signal-to-noise of the commit messages. I already personally use a standard commit message style.[1] And that standard is about how to structure the prose, not about using any kind of structured markup (outside the trailers section). > As for the `feat(scope):` in the subject line, it's a very succinct way to communicate the type of the change. Don't make me the read the whole commit to figure out if this was a feature or bug fix, or only affected the build. Verbs already serve that purpose most of the time. Then you get redundant lines like `feat: add OAuth 2.0 login`. > Sure. But I want the changelog to list features first, then bug fixes, etc. How do I do that automatically with only the git log w/o some sort of standardized tagging of the commits? If you have such a high volume of commits (that users would care about) that you have have distribute tagging of all commits to all contributors,[2] you can use the trailers section.[3] [1] I don’t expect anyone else to at work. In one free-time project people use the same style, with one exception (against my personal taste). [2] And if you need such a detailed changelog, let alone a fully automatically written one [3] https://news.ycombinator.com/item?id=40820213 https://news.ycombinator.com/item?id=40820213