undefined | Better HN

0 pointswincent6y ago0 comments

> Why?

The machine-readable part is useful for generating changelogs (eg. broken out by type) or implementing semver (eg. detecting breaking changes).

0 comments

hakre6y ago

but isn't it an antipattern to generate change-logs from commit subject lines?

wincentOP6y ago

That all depends on what you do with the meta-data in the commits. For example, at my work, we analyze the history at the level of merges, not commits, and that works pretty well for us.

cyphar6y ago

Merge information is incredibly useful to developers (even if only to provide a smart "git bisect"). But would you generate a user-visible changelog from your merges? I personally wouldn't, and that's the point GP was making.

1 more reply

wincentOP6y ago

That all depends on what you do with the meta-data in the commits. For example, in my work, we analyze the history at the level of merges, not commits, and that works pretty well for us.

ratherbefuddled6y ago

Of course not. How else would you do it?

cyphar6y ago

Have a dedicated changelog you maintain[1].

Patch descriptions are for developers, not for users -- aside from the fact they're the wrong granularity (no user cares if it took 20 patches and three PR cycles to implement a feature), they should contain details and justification that are only useful for future debugging or for review purposes (which users also don't care about). And if you have a bugfix for a previously-merged patch that hasn't yet been released, why would you include the bugfix in the changelog?

Yes, with the right format and discipline you could generate reasonable changelogs from your commit logs -- but at that point it's so much easier to just keep a CHANGELOG.md.

[1]: https://keepachangelog.com/en/1.0.0/

1 more reply

dchest6y ago

Make a human read the commit history (or tickets) and summarize changes in the language useful for users, not for developers.

2 more replies

j / k navigate · click thread line to collapse

0 comments

hakre6y ago

but isn't it an antipattern to generate change-logs from commit subject lines?

wincentOP6y ago

That all depends on what you do with the meta-data in the commits. For example, at my work, we analyze the history at the level of merges, not commits, and that works pretty well for us.

cyphar6y ago

1 more reply

wincentOP6y ago

That all depends on what you do with the meta-data in the commits. For example, in my work, we analyze the history at the level of merges, not commits, and that works pretty well for us.

ratherbefuddled6y ago

Of course not. How else would you do it?

cyphar6y ago

Have a dedicated changelog you maintain[1].

Yes, with the right format and discipline you could generate reasonable changelogs from your commit logs -- but at that point it's so much easier to just keep a CHANGELOG.md.

[1]: https://keepachangelog.com/en/1.0.0/

1 more reply

dchest6y ago

Make a human read the commit history (or tickets) and summarize changes in the language useful for users, not for developers.

2 more replies

j / k navigate · click thread line to collapse