Git-cliff – Generate changelog from the Git history

Original Article ↗ Hacker News Discussion ↗

Generating changelogs automatically from Git history, as tools like git-cliff do, promises to save maintainers time by leveraging structured commit messages (e.g., Conventional Commits) to produce release notes. Commenters are split on whether this yields useful, user-focused change information: supporters value the consistency, traceability, and integration with PR workflows, while critics argue it produces noisy, low‑signal logs that still require human curation and can burden developers with extra formatting discipline. Many see the best outcome as a hybrid approach, using auto-generated changelogs as an internal, engineering-oriented draft that is then edited into concise, user-facing release notes—potentially with help from LLMs or ticket-based workflows.

Overall impressions of git-cliff

  • Many like the idea and especially the terminal animation.
  • Some already use git-cliff in personal or team projects and report good results when combined with disciplined workflows (e.g., squash merges, well-written PR titles).
  • Others note that it appears regex-based, not AI-driven, despite the title suggesting an LLM-style task.

Value of auto-generated changelogs

  • Seen as a big time-saver vs. hand-writing changelogs or copy-pasting from git log.
  • Helpful for technical consumers who want a terse, linked summary rather than raw commits.
  • Often used as a first draft that can be manually curated, reordered, or summarized for end users.
  • Integration with GitHub releases/package managers is cited as a practical benefit.

Critiques and concerns

  • Strong worry about “noise”: trivial commits, refactors, doc tweaks, and implementation details users don’t care about.
  • Some argue that commit history and a good changelog serve different purposes, so mapping one directly to the other is “bad” or user-hostile.
  • Skepticism that teams with poor commit discipline will magically improve just because a tool is adopted.

Conventional Commits & enforcement

  • git-cliff is usually paired with Conventional Commits; this allows grouping by type (feat/fix/etc.) and scope.
  • Supporters say this shifts changelog decisions to commit time and can be enforced via hooks or PR rules.
  • Critics dislike the visual noise, low information density, and added cognitive load for every commit.
  • Some prefer Git trailers or separate changelog snippets in files over encoding structure in the subject line.

Changelog vs. release notes

  • Repeated distinction:
    • Changelog = technical, comprehensive, often auto-generated.
    • Release notes = curated, user-focused, sometimes written by technical writers.
  • Some see an intermediate “changelog” step as useful; others think it just duplicates git log plus curated notes.

Alternative approaches & tools

  • Mention of other tools: semantic-release, cocogitto, commitizen, conventional-pre-commit, custom scripts, ticket-based workflows, and per-change “snippet” files.
  • Some teams tie notes to tickets or separate branches/metadata instead of commit messages.
  • A few suggest LLMs as a potentially better way to summarize commit history, with human review.

UX and documentation feedback

  • Requests for clearer examples and better discoverability on git-cliff’s site.
  • Some think auto-generation is “better than nothing” but not a replacement for thoughtful human-written notes.