orhun / git-cliff

A highly customizable Changelog Generator that follows Conventional Commit specifications ⛰️

Documentation | Website

git-cliff can generate changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers. The changelog template can be customized with a configuration file to match the desired format.

Documentation

Learn how to use git-cliff from the documentation.

• Installation
• Usage
• Configuration
• Templating

In The Media

• Turning Git commits into changelog with git-cliff - RustLab 2023 (Talk)
• An Interview with Orhun of git-cliff - Console #141 (Newsletter)

Editor Support

• git-cliff.el - Generate, update and release changelog in Emacs

Similar/Related Projects

• git-journal - The Git Commit Message and Changelog Generation Framework
• clog-cli - Generate beautiful changelogs from your Git commit history
• relnotes - A tool to automatically generate release notes for your project.
• cocogitto - A set of CLI tools for the conventional commit and semver specifications.
• cliff-jumper - A NodeJS CLI tool that combines git-cliff and conventional-recommended-bump to semantically bump a NodeJS package and generate a git-cliff powered changelog.
• release-plz - Release Rust packages from CI.
• git-changelog-command-line - Generate changelog and determine next version with conventional commits.

Contributors

Thanks goes to these wonderful people ✨

Made with contrib.rocks.

Socials

License

Licensed under either of Apache License Version 2.0 or The MIT License at your option.

Copyright

Copyright © 2021-2024, git-cliff contributors

git-cliff's Issues

Allow minimal settings to build on defaults

The current config file system seems to require all required keys to be present. I am more comfortable with (and most programs support) only setting the values that I want to be different than the defaults. It would be nice if this was possible.

Is it possible to generate single changelog for multiple git projects

Multiline commit messages not being fully captured

Describe the bug
This might just be my misunderstanding of how to format conventional commits, but I am running into an issue where git-cliff is not picking up the full message of multiline commits. I would expect it to be able to include the full commit message in the changelog even if it has newlines present.

To Reproduce
Steps to reproduce the behavior:

1. Create a multiline commit message.
   
   The full message appears in the gitlog.
   

2. However when I create the changelog, only the message up to the newline is present.
   

Expected behavior
I would expect it to be able to include the full commit message in the changelog even if it has newlines present.

System (please complete the following information):

• OS Information: Windows 10
• Git-cliff version: 0.4.2

Configure from section in Cargo.toml

Having a separate config file just for a few values (hint hint #45) seems like overkill.

It seems like it would be pretty easy to check for a custom section in Cargo.toml for Rust projects. As a bonus with some json maybe also look at package.json, pyproject.toml, etc. Most of these formats allow project meta data in custom keys.

Extreme memory usage when running it on the linux kernel repo with cliff.toml from this project

Describe the bug
When running it on https://github.com/torvalds/linux with the cliff.toml from this repository, the git-cliff process will take a lot of time and consume more and more memory. I had to stop it at 12GB.

To Reproduce
Steps to reproduce the behavior:

git clone https://github.com/torvalds/linux
cp cliff.toml ./linux/
cd linux
git cliff

Expected behavior
A log is produced in reasonable time.

System (please complete the following information):

Ran f1b495d on MacOS with 8GB of RAM and M1

Question for commit filtering

Hello, we're evaluating using git-cliff for our monorepo, in order to automate the generation of the CHANGELOG. The tool looks really powerful!

We have a couple of questions:

• is it possible to ignore commits, if they all concern files under a common path? To explain the use case, our monorepo holds both libraries and apps. The apps live under the same folder, "apps". The changelog is only supposed to contain the changes of the libraries, which live in multiple folders. So if a commit only contains changes against paths under "apps/*", we'd like to filter them out if possible.
• is it possible to only process merge commits? We always work with merge requests and this ends up in the default branch as either one squashed commit or multiple commits + merge commit. I believe it is possible in Git to determine if a commit belongs to a merge commit by checking its parents (I don't remember it 100%). Can git-cliff identify and exclude commits that are referenced by a merge commit? Otherwise we'll end up with duplicate messages in the changelog.

How to regex replace strings?

Hey, great project but was wondering if it is possible to perform regex replacements in values like commit messages.

Something like {{ commit.message | replace(from="#(\d+)", to="") }} to turn Update dependencies (#57) into Update dependencies

Can't install v0.4.0 from cargo

Describe the bug
I can't get cargo to update git-cliff to v0.4.0 (I'm on v0.3.0). I tried to uninstall and install again, but it fetches v0.3.0

To Reproduce
Steps to reproduce the behavior:

1. Install v0.3.0
2. Attempt to upgrade to v0.4.0
3. See error

or

1. Uninstall v0.3.0
2. Attempt to install v0.4.0
3. See error

Expected behavior
I expect to be able to update or install the new version

Screenshots/Logs
error: could not find git-cliff in registry crates-io with version =0.4.0

System (please complete the following information):

• OS Information: macOS 11.6
• Project Version: 0.3.0

Comply with MD022?

Is your feature request related to a problem? Please describe.

The default configuration generates the changelog that violates a markdownlint rule MD022.

If there are no reasons for this, I feel it would be nice to comply with MD022.

Describe the solution you'd like

Just to add \n after # Changelog.

Before:

header = """
# Changelog
All notable changes to this project will be documented in this file.\n
"""

After:

header = """
# Changelog\n
All notable changes to this project will be documented in this file.\n
"""

Describe alternatives you've considered

Replace \n with a newline.

header = """
# Changelog

All notable changes to this project will be documented in this file.\n
"""

Additional context

Nothing.

Do not group by tag version

Is your feature request related to a problem? Please describe.
Sorry, I am not sure if this already doable and I missed it, but what I am interested in is to generate a changelog between two tags. But if the two tags contain other tags in between I do not want to see the inbetween tag versions.

The actual example is that if there are tags like:

v1.0.0. v1.1.0a1, v1.1.0b1, v1.1.0b2, v1.1.0

I might want to have changelogs for releases between v1.0.0 and v1.1.0a1 or v1.1.0a1 and v1.1.0b1 etc, but when I release the final v1.1.0 I want to create another changelog between v1.0.0 and v1.1.0 but without the intermediary tags (there might be a ton of them)

Describe the solution you'd like
I guess, a parameter that does not group by tags?

Additional context
Here is a dump of what git-cliff currently generates as changelog between two tags:

➜ git cliff v0.40..v0.45
# Changelog
All notable changes to this project will be documented in this file.

## [0.45] - 2021-05-26

### Infra

## [0.44] - 2021-05-24

### Feat

### Fix

## [0.43] - 2021-05-07

### Feat

### Fix

### Infra

## [0.42] - 2021-04-24

### BREAKING

### Feat

### Fix

## [0.41] - 2021-04-14

### BREAKING

<!-- generated by git-cliff -->

Include tags from other branches

Describe the bug
Tags which are on release branches and not on the default branch are ignored and the commits are marked as Unreleased. We are migrating to release branches at the moment and therefore there are tags on the main branch.

To Reproduce
Steps to reproduce the behavior:

1. Create repository
2. Create some commits and tags on the main branch
3. Create release branch
4. Do some changes on the release branch
5. Set the tag on the release branch
6. Execute git tags --list with the pattern used in the config file

Expected behavior
The git tags are included as versions in the changelog. The diff for the commits is done by comparing 2.3.4...6.5.4

System:

• OS Information: Ubuntu WSL2
• Project Version: 0.5.0

Add GitLab CI usage example to README.md

Is your feature request related to a problem? Please describe.
It would be nice to see an example in the documentation for the usage of git-cliff with GitLab CI.

Describe the solution you'd like
Add an example .gitlab-ci.yml to README.md, preferably after the github-action section.

Describe alternatives you've considered
None

Additional context
#20

Certain scopes are excluded from the `conventional_commits` filter

Describe the bug
Some conventional_commits are not marked as conventional_commits. We're using scopes with underscores and those commits are not seen as conventional. This is valid though: https://github.com/conventional-commits/parser#the-grammar

To Reproduce
Steps to reproduce the behavior:

1. Create a new commit. For example: feat(my_feature): add the new 'my' feature
2. See that it's not included in the changelog when the conventional_commits config setting is true.

Expected behavior
It should be added as it's a valid conventional commit message.

System (please complete the following information):

• OS Information: not relevant
• Project Version: 0.4.0

Additional context
Add any other context about the problem here.

I think this problem occurs in the git-conventional dependency. I also made an issue there:
crate-ci/git-conventional#17

Generate changelog for submodules

Is your feature request related to a problem? Please describe.
If my repository contains submodules and I have commits updating the submodule, I only see the a commit doing the update.
The information what changed in the submodule is not visible.

If the submodule also follow the same commit convention I would like to have a way to also include the submodule commits in my changelog.

Describe the solution you'd like

Add an option to recurse into submodules.
With this option enabled, git-cliff would, whenever it encounters a commit changing a submodule revision, recurse into this submodule.
It would then get the list of all commits included in this version change and include them in the current changelog. Maybe separated by submodule to allow nicely group them in the output.

Describe alternatives you've considered

• Implement this behaviour in an external script and merge the generated MRs
• Use subtrees instead of submodules

Additional context

Allow define sort on cliff.toml

Is your feature request related to a problem? Please describe.

Is not a problem, but is easier to share cliff.toml with all required config than share the file and ask people to pass the sort parameter when run.

a tera variable or filter for `previous_version`

For context:
I'm using in my changelog usually links that point to GitHubs version compare pages like this:

## [Unreleased]
[Unreleased]: https://github.com/steganogram/stegano-rs/compare/v0.5.0...HEAD

## [0.4.10] - 2021-11-15
[0.4.10]: https://github.com/steganogram/stegano-rs/compare/v0.4.10...v0.4.9

so there are links that points to the GitHub code compare, for the actual version (v0.4.10) with the "previous" (v0.4.9) semver version that was released, and the last released version (v0.5.0) with the HEAD

In order to make this same changelog available by cliff I've tried the cliff.toml as below:

# template for the changelog body
# https://tera.netlify.app/docs/#introduction
body = """
{% if version %}\
    ## [{{ version | trim_start_matches(pat="v") }}] {{ timestamp | date(format="%Y-%m-%d") }}
    [{{ version | trim_start_matches(pat="v") }}]: https://github.com/sassman/putzen-rs/compare/{{ version }}...{{ previous_version }}
{% else %}\
    ## [unreleased]
    [Unreleased]: https://github.com/sassman/putzen-rs/compare/{{ latest_version }}...HEAD
{% endif %}\

I guess this variables could be very tricky to provide, but maybe when assuming semver version tags it might be possible to have them all parsed and prepared for the tera rendering.

Alternatively it might be a filter available that goes to the previous version of a given version number like this:

    [{{ version | trim_start_matches(pat="v") }}]: https://github.com/sassman/putzen-rs/compare/{{ version }}...{{ version | previous_release }}

The global configuration file has the highest priority

Thank you for creating a great tool.
I'm sorry if the behavior this is a specification.

Describe the bug

The global configuration file has the highest priority.
Is this the expected behavior?
Load the global configuration file even if cliff.toml is in the current directory.

To Reproduce

1. Create git repository.
2. Create git-cliff three configuration files.
   • local (cliff.toml)
   • global (~/.config/git-cliff/cliff.toml)
   • The file specified by --config (config.toml)
3. run git cliff
   Load global configuration file.
4. run git cliff --config config.toml
   Load global configuration file.

Expected behavior

This is an environment with a global configuration file.

• git cliff
  • cliff.toml exists in the current directory:: Load cliff.toml in the current directory.
  • cliff.toml does not exists in the current directory:: Load global configuration.
• git cliff --config <PATH>
  • <PATH> exists:: Load <PATH>.
  • <PATH> does not exist:: Load embedded default configuration file into the binary.

Screenshots/Logs

Check the file exists & Check diff

$ ls
cliff.toml  config.toml
$ diff cliff.toml config.toml
6c6
< # local config
---
> # config option
27c27
< <!-- local config -->
---
> <!-- config option -->
$ diff cliff.toml ~/.config/git-cliff/cliff.toml
6c6
< # local config
---
> # global config
27c27
< <!-- local config -->
---
> <!-- global config -->

A global configuration file exists

$ git cliff
# global config
## [unreleased]

### Miscellaneous Tasks

- Add git-cliff toml

<!-- global config -->

$ git cliff --config config.toml
# global config
## [unreleased]

### Miscellaneous Tasks

- Add git-cliff toml

<!-- global config -->

A global configuration file does not exist

$ rm ~/.config/git-cliff/cliff.toml
$ git cliff
# local config
## [unreleased]

### Miscellaneous Tasks

- Add git-cliff toml

<!-- local config -->

$ git cliff --config config.toml
# config option
## [unreleased]

### Miscellaneous Tasks

- Add git-cliff toml

<!-- config option -->

System (please complete the following information):

• OS Ubuntu 20.04 LTS (WSL2)
• Project Version: 2be04f8b2214513d08d349b254a97a8c783073fb

Additional context

Current Behavior

This is an environment with a global configuration file.

• git cliff
  • cliff.toml exists in the current directory:: Load global configuration file.
  • cliff.toml does not exists in the current directory:: Load global configuration file.
• git cliff --config <PATH>
  • <PATH> exists:: Load global configuration file.
  • <PATH> does not exist:: Load global configuration file.

References

• Global configuration file and builtin configuration · Issue #2 · orhun/git-cliff
• lib.rs

Thank you.

History of hotfix gets combined with unreleased section

First of all I really like the simplicty of git-cliff, but I encountered an issue where I don't know, if we are using it correct or not. It sounds like a little bit like #29, but I'm not sure.

Description
In the project I'm working on we have a git-flow like branching model at the moment. We created from develop the version v1.0.0 and merged these changes to master. Afterwards we continued our work on v1.1.0 on develop in the meanwhile, but later an urgent issue for v1.0.0 occured and we had to create an hotfix v1.0.1.

We created an branch hotfix/1.0.1 from master and merged these changes back to master and develop, but on develop the work continued and after the merge of hotfix/1.0.1 into develop the changelog now combines the changes from the hotfix with the unreleased changes on develop.

Actual Output

*   1473da8 (HEAD -> develop) Merge branch 'hotfix/1.0.1' into develop
|\  
| * 6134a57 (tag: v1.0.1, master, hotfix/1.0.1) fix: v1.0.1
* | 5ce33a7 chore: start work on v1.1.0
|/  
* a6915e6 (tag: v1.0.0) feat: v1.0.0

The corresponding changelog looks like this:

# Changelog
All notable changes to this project will be documented in this file.

## [1.0.1] - 2021-12-01

### Bug Fixes

- v1.0.1

### Miscellaneous Tasks

- Start work on v1.1.0

## [1.0.0] - 2021-11-01

### Features

- v1.0.0

Expected Output

# Changelog
All notable changes to this project will be documented in this file.

## [unreleased]

### Miscellaneous Tasks

- Start work on v1.1.0

## [1.0.1] - 2021-12-01

### Bug Fixes

- v1.0.1

## [1.0.0] - 2021-11-01

### Features

- v1.0.0

Question
How can we prevent that the hotfix changes an the unreleased changes are combined by their commit date?

Previous not populated when using --tag and --unreleased

Describe the bug
git cliff --unreleased --tag 14.0.0 --prepend ./CHANGELOG.md

If a repo is needed:
https://github.com/discordjs/discord.js

Running:
cd packages/discord.js
git cliff --unreleased --tag 14.0.0 --prepend ./CHANGELOG.md -c ../../cliff.toml -r ../../

Will reproduce it, otherwise similar steps will most likely work too on any repo.

To Reproduce

[changelog]
header = """
# Changelog
All notable changes to this project will be documented in this file.\n
"""
body = """
{% if version %}\
    # [{{ version | trim_start_matches(pat="v") }}]\
    {% if previous %}\
        {% if previous.version %}\
            (https://github.com/discordjs/discord.js/compare/{{ previous.version }}...{{ version }})\
        {% else %}
            (https://github.com/discordjs/discord.js/tree/{{ version }})\
        {% endif %}\
    {% endif %} \
    - ({{ timestamp | date(format="%Y-%m-%d") }})
{% else %}\
    # [unreleased]
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
    ## {{ group | upper_first }}
    {% for commit in commits %}
        - {% if commit.breaking %}\
            [**breaking**] \
          {% endif %}\
            {% if commit.scope %}\
                **{{commit.scope}}:** \
            {% endif %}\
            {{ commit.message | upper_first }} ([{{ commit.id | truncate(length=7, end="") }}](https://github.com/discordjs/discord.js/commit/{{ commit.id }}))\
    {% endfor %}
{% endfor %}\n
"""
trim = true
footer = ""

[git]
conventional_commits = true
filter_unconventional = true
commit_parsers = [
    { message = "^feat", group = "Features"},
    { message = "^fix", group = "Bug Fixes"},
    { message = "^docs", group = "Documentation"},
    { message = "^perf", group = "Performance"},
    { message = "^refactor", group = "Refactor"},
    { message = "^typings", group = "Typings"},
    { message = "^types", group = "Typings"},
    { message = ".*deprecated", body = ".*deprecated", group = "Deprecation"},
    { message = "^revert", skip = true},
    { message = "^style", group = "Styling"},
    { message = "^test", group = "Testing"},
    { message = "^chore", skip = true},
    { message = "^ci", skip = true},
    { message = "^build", skip = true},
    { body = ".*security", group = "Security"},
]
filter_commits = true
tag_pattern = "[0-9]*"
skip_tags = "v[0-9]*|11|12"
ignore_tags = ""
topo_order = false
sort_commits = "newest"

Expected behavior
Expect previous to be populated to based on the latest actual tag so the desired compare link can be generated with the config above.

Screenshots/Logs
Generated by creating a git tag manually and then running: git cliff --latest --prepend ./CHANGELOG.md

Generated by not creating a git tag and running git cliff --unreleased --tag 14.0.0 --prepend ./CHANGELOG.md

System (please complete the following information):

• OS Information: [Windows 11 Pro / 10.0.22000 Build 22000]
• Project Version: [dev-build 8bb48b0]

check if a commit message follows conventional commit spec

Is your feature request related to a problem? Please describe.
no

Describe the solution you'd like
use git cliff in git hook to check that a given commit message or a message given as parameter match conventional syntax

Describe alternatives you've considered
using a script, but git cliff has everything internally to do the job and can follow the project specific syntax from its toml config file

Additional context

Previous not populated when using `--latest`

Describe the bug

When using "latest" previous is not set.

To Reproduce
Steps to reproduce the behavior:

Notes: experienced on PurpleBooth/git-mit, it has the config as defined below.

[changelog]
header = """## Changelog
"""
body = """
{% if version %}\
    {% if previous %}\
        ### [{{ version }}](https://github.com/PurpleBooth/git-mit/compare/{{ previous.version }}...{{ version }}) ({{ timestamp | date(format="%Y-%m-%d") }})
    {% else %}\
        ### [{{ version }}](https://github.com/PurpleBooth/git-mit/tree/{{ version }}) ({{ timestamp | date(format="%Y-%m-%d") }})
    {% endif %}\
{% else %}\
    ### [unreleased]
{% endif %}\
{% if previous %}\
    {% if previous.commit_id %}
        [{{ previous.commit_id | truncate(length=7, end="") }}]({{ previous.commit_id }})...\
            [{{ commit_id | truncate(length=7, end="") }}]({{ commit_id }})
    {% endif %}\
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
    ### {{ group | upper_first }}
    {% for commit in commits %}
        - {{ commit.message | upper_first }} ([{{ commit.id | truncate(length=7, end="") }}]({{ commit.id }}))\
    {% endfor %}
{% endfor %}\n
"""
trim = true

[git]
conventional_commits = true
tag_pattern = "v[0-9]*"

Expected behavior
A clear and concise description of what you expected to happen.

I would expect previous to always be set, so we can correctly generate compare URLs for Github.

Screenshots/Logs

$ git-cliff | head
## Changelog
### [unreleased]

### Fix

- Update the changelog ([70bd7ff](70bd7ffe55857940e898f5b97b34b2f62acd1c8e))

### [v4.0.14](https://github.com/PurpleBooth/git-mit/compare/v4.0.13...v4.0.14) (2021-08-14)

[88ef7ec](88ef7ecd813d32f19804421acf3daa3e396d48e2)...[fb1afd9](fb1afd98c2c290fee748c89fde064667f49b8cda)

$ git-cliff --latest | head
## Changelog
### [v4.0.14](https://github.com/PurpleBooth/git-mit/compare/...v4.0.14) (2021-08-14)

### Build

- Versio update versions ([fb1afd9](fb1afd98c2c290fee748c89fde064667f49b8cda))

### Chore

- Update FUNDING.yml ([651ef61](651ef61ed10923c6e451bd63dae4b038c845ad2e))

System (please complete the following information):

• OS Information: [e.g. Arch GNU/Linux x86_64 5.4.8-arch1-1]
• Project Version: [e.g. 0.1.0]

$ sw_vers
ProductName:    macOS
ProductVersion: 11.5.1
BuildVersion:   20G80

$ git-cliff --version
git-cliff 0.1.0

Additional context
Add any other context about the problem here.

scopes `(*)` are skipped

Describe the bug
A clear and concise description of what the bug is.

When commit scope is (*) or * it isn't generated

To Reproduce
Steps to reproduce the behavior:

1. commit with something like feat(*): user authentication
2. generate
3. missing

Expected behavior
the item get added with default_scope and to be treated as if it's feat: user authentication

System (please complete the following information):

• OS Information: MacOS
• Project Version: [0.4.0]

Additional context

cliff configuration: https://gist.github.com/tami5/1044c256a173c622847114cc3bcd0ffd

Cannot install git-cliff from crates-io due to missing `config` folder

Describe the bug

Cannot install git-cliff from crates-io due to missing config folder.

Hunch: If the build process requires the config folder, it must be specified to be included to via a cargo manifest key https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields (note that you need to specify everything to include then, the globs need to be added explicitly).

To Reproduce
Steps to reproduce the behavior:

1. `cargo install -f git-cliff

Expected behavior

Build and install the binary.

Screenshots/Logs

   Compiling git-cliff-core v0.2.3
error: proc-macro derive panicked
  --> /home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/git-cliff-core-0.2.3/src/embed.rs:16:17
   |
16 | #[derive(Debug, RustEmbed)]
   |                 ^^^^^^^^^
   |
   = help: message: #[derive(RustEmbed)] folder '/home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/git-cliff-core-0.2.3/../config/' does not exist. cwd: '/home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/git-cliff-core-0.2.3'

error[E0599]: no function or associated item named `get` found for struct `EmbeddedConfig` in the current scope
  --> /home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/git-cliff-core-0.2.3/src/embed.rs:23:15
   |
18 | pub struct EmbeddedConfig;
   | -------------------------- function or associated item `get` not found for this
...
23 |         match Self::get(crate::DEFAULT_CONFIG) {
   |                     ^^^ function or associated item not found in `EmbeddedConfig`
   |
   = help: items from traits can only be used if the trait is implemented and in scope
   = note: the following traits define an item `get`, perhaps you need to implement one of them:
           candidate #1: `SliceIndex`
           candidate #2: `bitvec::slice::api::BitSliceIndex`
           candidate #3: `lexical_core::util::sequence::SliceLike`
           candidate #4: `RustEmbed`

error: aborting due to 2 previous errors

System (please complete the following information):

• OS Information: [e.g. Arch GNU/Linux x86_64 5.4.8-arch1-1] Fedora 34
• Project Version: [e.g. 0.1.0] 0.2.3

Possibly replace git-conventional with conventional-commit-parser

Is your feature request related to a problem? Please describe.

Hi @orhun

This is not directly related to git-cliff, as you know I am refactoring the cocogitto changelog logic to use git-cliff internals.

Now I am facing the following dilemma :
cocogitto uses conventional_commit_parser, git-cliff uses git-conventional which does exactly the same.
In order to integrate git-cliff I need either to use git-conventional and drop conventional_commit_parser or do the opposite in
git-cliff.

Describe the solution you'd like
I am biased toward the library I wrote but I think it has a few cons :

• Slightly smaller crate size ( 11.3 kB vs 14kB)
• Pest grammar is easy to read, so probably easier to maintain
• I removed all string allocations from the latest version to improve perfs and look more like git-conventional API

If you are ok with this I can make a draft PR in git-cliff.

Describe alternatives you've considered

If you have some good reason to stick with git conventional I'll refactor on cocogitto's side to get this done. Let me know.

Skip all tags, when `skip_tags = ""`

I'm sorry if the behavior this is a specification.

Describe the bug

Skip all tags, when skip_tags = "".
Is this the expected behavior?

To Reproduce

I've created a test script.

test script

#!/bin/bash
set -e

rm -rf /tmp/cliff/skip_tags_test
mkdir -p /tmp/cliff/skip_tags_test
cd /tmp/cliff/skip_tags_test

git init

git commit --allow-empty -m "chore: v0.0.1"
git tag v0.0.1

git commit --allow-empty -m "feat: v0.1.0-beta.1"
git tag v0.1.0-beta.1

git commit --allow-empty -m "feat: v0.1.0"
git tag v0.1.0

git cliff --init

echo '====================================='
echo 'skip_tags = "v0.1.0-beta.1" (Default)'
echo '====================================='
git cliff

sed -i 's/\(skip_tags = \)"v0.1.0-beta.1"/\1""/' cliff.toml
echo '====================================='
echo 'skip_tags = ""'
echo '====================================='
git cliff

sed -i 's/skip_tags.*//' cliff.toml
echo '====================================='
echo 'skip_tags is unset.'
echo '====================================='
git cliff

output

Initialized empty Git repository in /tmp/cliff/skip_tags_test/.git/
[main (root-commit) c57e04c] chore: v0.0.1
[main fe30e5e] feat: v0.1.0-beta.1
[main 9492956] feat: v0.1.0
 INFO  git_cliff > Saving the configuration file to "cliff.toml"
=====================================
skip_tags = "v0.1.0-beta.1" (Default)
=====================================
# Changelog

All notable changes to this project will be documented in this file.

## [0.1.0] - 2022-02-19

### Features

- V0.1.0

## [0.0.1] - 2022-02-19

### Miscellaneous Tasks

- V0.0.1

<!-- generated by git-cliff -->
=====================================
skip_tags = ""
=====================================
# Changelog

All notable changes to this project will be documented in this file.

<!-- generated by git-cliff -->
=====================================
skip_tags is unset.
=====================================
# Changelog

All notable changes to this project will be documented in this file.

## [0.1.0] - 2022-02-19

### Features

- V0.1.0

## [0.1.0-beta.1] - 2022-02-19

### Features

- V0.1.0-beta.1

## [0.0.1] - 2022-02-19

### Miscellaneous Tasks

- V0.0.1

<!-- generated by git-cliff -->

skip_tags = ""

# Changelog

All notable changes to this project will be documented in this file.

<!-- generated by git-cliff -->

Expected behavior

I expect don't skip all tags, as when skip_tags is unset.

skip_tags is unset.

# Changelog

All notable changes to this project will be documented in this file.

## [0.1.0] - 2022-02-19

### Features

- V0.1.0

## [0.1.0-beta.1] - 2022-02-19

### Features

- V0.1.0-beta.1

## [0.0.1] - 2022-02-19

### Miscellaneous Tasks

- V0.0.1

<!-- generated by git-cliff -->

System (please complete the following information):

• OS Ubuntu 20.04 LTS (WSL2)
• Project Version: 761669eb575cd3195554e2a5c680c62bcee4f99b

Additional context

Code that may be relevant.

git-cliff/git-cliff/src/lib.rs

Lines 124 to 130 in 761669e

	let skip_regex = config.git.skip_tags.as_ref();
	let ignore_regex = config.git.ignore_tags.as_ref();
	tags = tags
	.into_iter()
	.filter(|(_, name)| {
	// Keep skip tags to drop commits in the later stage.
	let skip = skip_regex.map(|r| r.is_match(name)).unwrap_or_default();

I have changed to the following code.

let skip = skip_regex.map(|r| r.is_match(name)).unwrap_or_default();
println!("{}", skip);

println!("{}", skip); output true always, when skip_tags = "".

Thank you.

Specify a subpath to build the changelog

Hi,
In the context of a mono-repo, is it possible to specify the repository subpath to build the changelog from ?

Something like git cliff -- subpath/

Thanks.

Group order doesn't match the order of `commit_parsers`

Describe the bug
As I was tweaking my cliff.toml file to get the changelog to look exactly how I want it, I noticed the order of the groups is not affected by the elements in commit_parsers, but rather seems to be alphabetical on the group name.

Expected behavior
I hoped the groups would appear in the markdown in the same order as the commit_parsers array. Maybe there's a way to work around this? Thanks!

Tag parser seem to remove all "v" from version tags by default

Describe the bug
In the Mission Pinball Framework we tag our commits as v0.56-dev.0 for development releases. Unfortunately, in git cliff those show up as 0.56-de.0 (notice the missing v).

Is there any guide how to change the tag regex? Standard perl syntax does not seem to work.

To Reproduce

1. Tag a commit as ``v0.56-dev.0`
2. Add some commits on top
3. Run git cliff

Expected behavior
I would like cliff to show 0.56-dev.0 in the headline instead of 0.56-de.0.

Screenshots/Logs

## [0.56-de.0] - 2021-07-25

Regex preprocess commit messages

Is your feature request related to a problem? Please describe.
Our CI system prepends all changes which are merged by using the PR functionality (by policy everyone has to do so) with "Merged PR xxx: ". This does not comply with the conventional commit message format.

Describe the solution you'd like
Something like a commit message preprocessor which enables us to remove or select certain parts of the commit message/body to be used in the following processes.

Describe alternatives you've considered
Removing that prefix, which is unfortunately not possible.

Add an option for processing only the current tag

Is your feature request related to a problem? Please describe.

Currently, --latest option is supported, but it's a bit difficult to use.

Suppose this situation:

1. First, v0.10.0-test is released
2. After that, v0.11.0-test is released
3. After that, a bug was found and v0.10.1-test is released

Then the current behaviors are:

$ git checkout v0.10.0-test
$ git cliff | head
# Changelog
All notable changes to this project will be documented in this file.

## [0.10.0-test] - 2021-11-28

### Features

- Add A

## [0.9.0-test] - 2021-11-25

$ git cliff --latest
# Changelog
All notable changes to this project will be documented in this file.

## [0.10.1-test] - 2021-11-28

### Bug Fixes

- Fix A

<!-- generated by git-cliff -->

$ git checkout v0.11.0-test
$ git cliff | head
# Changelog
All notable changes to this project will be documented in this file.

## [0.11.0-test] - 2021-11-28

### Features

- Add B

## [0.10.0-test] - 2021-11-28

$ git cliff --latest
# Changelog
All notable changes to this project will be documented in this file.

## [0.10.1-test] - 2021-11-28

### Bug Fixes

- Fix A

<!-- generated by git-cliff -->

$ git checkout v0.10.1-test
$ git cliff | head
# Changelog
All notable changes to this project will be documented in this file.

## [0.10.1-test] - 2021-11-28

### Bug Fixes

- Fix A

## [0.10.0-test] - 2021-11-28

$ git cliff --latest
# Changelog
All notable changes to this project will be documented in this file.

## [0.10.1-test] - 2021-11-28

### Bug Fixes

- Fix A

<!-- generated by git-cliff -->

I want an option that extracts commits that are in only one release based on the current branch, but I guess there is nothing like that.

I believe it's useful for generating the body for GitHub Releases like you show here.
Currently, you use --latest for this, but since what --latest points to will change, it's difficult to use correctly.

Describe the solution you'd like
A clear and concise description of what you want to happen.

I guess adding --current option can solve this problem.
It behaves like this:

$ git checkout v0.10.0-test
$ git cliff --current
# Changelog
All notable changes to this project will be documented in this file.

## [0.10.0-test] - 2021-11-28

### Features

- Add A

<!-- generated by git-cliff -->

$ git checkout v0.11.0-test
$ git cliff --current
# Changelog
All notable changes to this project will be documented in this file.

## [0.11.0-test] - 2021-11-28

### Features

- Add B

<!-- generated by git-cliff -->

$ git checkout v0.10.1-test
$ git cliff --current
# Changelog
All notable changes to this project will be documented in this file.

## [0.10.1-test] - 2021-11-28

### Bug Fixes

- Fix A

<!-- generated by git-cliff -->

Describe alternatives you've considered

Extracting the section of the current release using some text processing tools can achieve the same thing, but it's a bit troublesome.

Additional context

If I switch the order of creating tags, for example v0.11.0-test after v0.10.1-test, --latest will point to v0.11.0-test, so I feel it's hard to estimate.

Running git cliff in the Gitlab CI results in an 'IO error'

// offtopic: git-cliff is my favourite changelog generation tool after trying a lot of them. So thanks for that!

Describe the bug
When running git-cliff in the Gitlab CI. The tool results an IO error. Not sure where to go from here. Executing pwd gives the correct path, that includes a .git directory.

Expected behavior
It would run in the same way as it does locally.

Screenshots/Logs

System (please complete the following information):

• OS Information: CI image is an alpine based image
• Project Version: 0.4.0 musl

Question: releasing v0.4.1

Hi @orhun,

Is there any chance in releasing version v0.4.1? Mainly because of #26. This is something blocking in our usage of git-cliff.

Thanks in advance!

Add a man page

Is your feature request related to a problem? Please describe.

A man page should be added to the project for accessing the documentation using man(1):

$ man git-cliff

Describe the solution you'd like

Add a man page under docs/ in the root directory of the project. It should contain information about the command line arguments, configuration file sections/fields and the basic usage.

There are 2 possible ways that I can think of to achieve this:

• Add the markdown representation of a man page (for readability) and use a 3rd party tool for conversion.
  • docs/git-cliff.md
  • Tools for conversion: pandoc or mandown
  • README.md should be updated about conversion instructions.
• Add the groff file
  • docs/git-cliff.1
  • help2man(1) can be used for assistance.

Describe alternatives you've considered
None.

Additional context
None.

Grouping multiple matches from commit message

It could be interesting supports multiple matches into the same no conventional commit message.
For example, on the same commit:

Summary of my commit

new: added something amazing
fix: solved problem
refactor: i've rewritten an entire class

git cliff should generate relative group for each match (Features, Bug Fix, Refactor etc.)

• Features
  • added something amazing
• Bug fix
  • solved problem
• Refactor
  • i've rewritten an entire class

Identify fingerprint of, and sign, key used to sign packages

It's possible I've missed it somewhere, but I cannot find where you've identified the key used to sign your release tarballs. gpg identifies the signature as having been made by key 1D2D410A741137EBC544826F4A92FA17B6619297, but aside from that key sharing a name with this project, I have no way of knowing whether I should trust it.

Describe the solution you'd like
Identify the key fingerprint in your readme. Better yet, sign/trust your signing key with Orhun's key, 165E0FF7C48C226E1EC363A7F83424824B3E4B90, which is identified on their github profile.

Additional context
Having signatures for your Docker images would be nice as well.

Apologies if you've already put this somewhere and I've missed it!

Does not work `message` and `body` in `commit_parsers`

Describe the bug

commit_parsers.message includes body in the search range.
Similarly, commit_parsers.body includes message in the search range.

To Reproduce

1. Create git repository.
2. Create git-cliff configuration file.
3. Change git-cliff configuration.
4. Create commits.
5. Run git cliff.
   Output not as expected.

Details about the commit log, commit_parses, output CHANGELOG, etc. are described in "Screenshots/Logs".

Expected behavior

The search range of commit_parsers.message is message only.
The search range of commit_parsers.body is body only.

Screenshots/Logs

cliff.toml

[git]
conventional_commits = false
filter_unconventional = false
commit_parsers = [
    { message = "apple", group = "Apple"},
    { body = "banana", group = "Banana"},
]

The other values are default values.

git log

commit 469fba85058e6103ac1b892e4edde951f545ee0e (HEAD -> main)
Author: hituzi_no_sippo <[email protected]>
Date:   Sun Jan 30 15:46:21 2022 +0900

    banana

commit 61f0ea6765b321c7d23a7b2c31ed191c37dfbea3
Author: hituzi_no_sippo <[email protected]>
Date:   Sun Jan 30 15:45:54 2022 +0900

    camel

    apple

commit 3a819db2bdb0917d3864998dab5858afc8fc8da2
Author: hituzi_no_sippo <[email protected]>
Date:   Sun Jan 30 15:45:06 2022 +0900

    apple

git cliff

# Changelog
All notable changes to this project will be documented in this file.

## [unreleased]

### Apple

- Apple

- Camel

apple


### Banana

- Banana


<!-- generated by git-cliff -->

There is no apple in the message of the Camel, but it is listed in CHANGELOG.
There is no banana in the body of the Banana, but it is listed in CHANGELOG.

Expected

# Changelog
All notable changes to this project will be documented in this file.

## [unreleased]

### Apple

- Apple


<!-- generated by git-cliff -->

System (please complete the following information):

• OS Ubuntu 20.04 LTS (WSL2)
• Project Version: 2be04f8b2214513d08d349b254a97a8c783073fb

Additional context

Code that may be relevant

git-cliff/git-cliff-core/src/commit.rs

Lines 115 to 120 in 848d8a5

	for parser in parsers {
	for regex in vec![parser.message.as_ref(), parser.body.as_ref()]
	.into_iter()
	.flatten()
	{
	if regex.is_match(&self.message) {

Thank you.

Missing optional scopes

Is your feature request related to a problem? Please describe.
I cannot iterate over commits that are missing a scope.

According to the Tera docs of group-by, items that lack an attribute are discarded.

This means that if I want to have a scoped changelog, as per the git-cliff example, (and I do) then these commits are skipped from the changelog.

Describe the solution you'd like
I would like git-cliff to mark these commits in a specially named scope (maybe called unscoped? maybe have it configurable?) so I can iterate over them in my template and create a special section/heading for them

Describe alternatives you've considered
If git-cliff does not somehow mark these missing scopes, I do not believe there is an alternative on iterating over them.

Additional context
Some capture of the output of git-clif when scopes are missing:

# Changelog
All notable changes to this project will be documented in this file.

## [unreleased]

### Documentation

### Infrastructure

#### Ide

- Added git commit hooks for conventional messages
- Added suggested VS Code extensions

<!-- generated by git-cliff -->

Note the Documentation section that does not display any commits there (since the commit message is like docs: some commit message

Change scope with commit_parsers

Is your feature request related to a problem? Please describe.
In a monorepo, I that have a folder with the name "www", however, since I am using git-cliff to generate a public-facing changelog, I would wish for this to be displayed as "Application" when generated.

I am using template replace functions to replace "www" with "Application" but would like the ability to change this in the commit_parsers.

Describe the solution you'd like
commit_parsers should allow changing of the scope on-demand. For example:

commit_parsers = [
  { message = "(www)", scope = "Application" }
]

Describe alternatives you've considered
N/A

Additional context
Thanks for an awesome project!

Add breaking_description

Is your feature request related to a problem? Please describe.
A new release of git_conventionnal was just published who add breaking_description

Describe the solution you'd like
Add breaking_description to the available meta

Additional context
Could be used to generate Breaking Changes section in template easily.

Strange behaviour with "parallel" codelines

Describe the bug
Hey! I'm seeing some odd results when generating a changelog if the most recent tag (chronologically) is not in the same version line. I'm not sure if it's something I'm doing wrong... 🤔

To Reproduce

1. I created a new repository and added commits and tags to master as follows (most recent on top, as per git log:

   feat: fifth commit on master
   feat: fourth commit on master  <-- tag v0.2.0
   chore: third commit on master
   fix: second commit on master   <-- tag v0.1.0
   feat: first commit on master
   

2. Then I pretended I had a fix I needed to make on the v0.1.x line, so I checked out the tag, started a new branch and made a commit:

   fix: patch on v0.1.x          <-- tag v0.1.1
   fix: second commit on master  <-- tag v0.1.0
   feat: first commit on master
   

3. When I generate the changelog for v0.1.1, I get the result I expected ("Patch on v0.1.x"), however the changelog for the unreleased commit on master is not:

   # Changelog
   All notable changes to this project will be documented in this file.
   
   ## [unreleased]
   
   ### Features
   
   - Fifth commit on master
   
   ## [0.2.0] - 2021-10-22
   
   ### Features
   
   - Fourth commit on master
   
   ### Miscellaneous Tasks
   
   - Third commit on master
   
   <!-- generated by git-cliff -->
   

   Using git cliff v0.2.0.. instead does give me the expected result.

Expected behavior
I expected the output of git cliff -u to be the same as git cliff v0.2.0.. in this case:

# Changelog
All notable changes to this project will be documented in this file.

## [unreleased]

### Features

- Fifth commit on master

<!-- generated by git-cliff -->

If this is the intended behaviour, just let me know and I'll adapt our CI jobs to use the explicit git refspec. Thanks! 🤗

Link PR and author by commits

Describe the solution you'd like

I'd love to automate generation of Changelog that's presented on serverless project, which:

• By each commit links PR with which it was introduced
• By each commit presents author name and links it to author's GitHub profile
• Allow to group changes by scope

Is that possible with git-cliff?

Commit filtering with --include-path yields no results in monorepo setup

Describe the bug
Running the command git cliff --prepend packages/discord.js/CHANGELOG.md -u --include-path 'packages/discord.js/*' gives me absolutely nothing.

If I remove the include-path it does, but then obviously commits that went into different packages are being thrown into that changelog too.

I do indeed run this command in each package git cliff --prepend ./CHANGELOG.md -l -c ../../cliff.toml -r ../../ --include-path './*' which should be fine, but I also tried the one mentioned above, which also does not work.

If a repo is needed:
https://github.com/discordjs/discord.js

Running:
git cliff --unreleased --prepend packages/discord.js/CHANGELOG.md --include-path 'packages/discord.js/*'

OR:
cd packages/discord.js
git cliff --unreleased --prepend ./CHANGELOG.md -c ../../cliff.toml -r ../../ --include-path './*'

Will reproduce it, otherwise similar steps will most likely work too on any repo.

To Reproduce

[changelog]
header = """
# Changelog
All notable changes to this project will be documented in this file.\n
"""
body = """
{% if version %}\
    # [{{ version | trim_start_matches(pat="v") }}]\
    {% if previous %}\
        {% if previous.version %}\
            (https://github.com/discordjs/discord.js/compare/{{ previous.version }}...{{ version }})\
        {% else %}
            (https://github.com/discordjs/discord.js/tree/{{ version }})\
        {% endif %}\
    {% endif %} \
    - ({{ timestamp | date(format="%Y-%m-%d") }})
{% else %}\
    # [unreleased]
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
    ## {{ group | upper_first }}
    {% for commit in commits %}
        - {% if commit.breaking %}\
            [**breaking**] \
          {% endif %}\
            {% if commit.scope %}\
                **{{commit.scope}}:** \
            {% endif %}\
            {{ commit.message | upper_first }} ([{{ commit.id | truncate(length=7, end="") }}](https://github.com/discordjs/discord.js/commit/{{ commit.id }}))\
    {% endfor %}
{% endfor %}\n
"""
trim = true
footer = ""

[git]
conventional_commits = true
filter_unconventional = true
commit_parsers = [
    { message = "^feat", group = "Features"},
    { message = "^fix", group = "Bug Fixes"},
    { message = "^docs", group = "Documentation"},
    { message = "^perf", group = "Performance"},
    { message = "^refactor", group = "Refactor"},
    { message = "^typings", group = "Typings"},
    { message = "^types", group = "Typings"},
    { message = ".*deprecated", body = ".*deprecated", group = "Deprecation"},
    { message = "^revert", skip = true},
    { message = "^style", group = "Styling"},
    { message = "^test", group = "Testing"},
    { message = "^chore", skip = true},
    { message = "^ci", skip = true},
    { message = "^build", skip = true},
    { body = ".*security", group = "Security"},
]
filter_commits = true
tag_pattern = "[0-9]*"
skip_tags = "v[0-9]*|11|12"
ignore_tags = ""
topo_order = false
sort_commits = "newest"

Expected behavior
Expect a changelog to be generated with only commits that target the specific folder and files mentioned in the --include-path

System (please complete the following information):

• OS Information: [Windows 11 Pro / 10.0.22000 Build 22000]
• Project Version: [dev-build 8bb48b0]

Change the behavior of skip_tags not to drop commits but to include them in the next tag

Is your feature request related to a problem? Please describe.

While testing this tool, I felt the skip_tags option behaves unnaturally.
The current behavior seems completely dropping commits from the changelog, but I believe that if a certain tag is skipped, it should be included in the next tag.

So for example, supposing the commits and tags are like the following and that skip_tags is v0.2.0-beta.1,

[v0.2.0] feat: add B
[v0.2.0-beta.1] fix: fix A
[v0.1.0] feat: add A

The current behavior is:

[v0.2.0]

## Feature

- Add B

[v0.1.0]

## Feature

- Add A

However, it should be:

[v0.2.0]

## Feature

- Add B

## Fix

- Fix A

[v0.1.0]

## Feature

- Add A

Describe the solution you'd like

Changing the behavior of skip_tags can solve the problem, I believe.

This is an example of the implementation.
kenji-miyake@89d0bf4

How to test:

$ git clone [email protected]:kenji-miyake/git-cliff.git -b main
$ cd git-cliff

$ # Before
$ cargo run | grep -A 20 "0.1.0-beta.2"
   Compiling git-cliff v0.4.2 (/tmp/git-cliff/git-cliff)
    Finished dev [unoptimized + debuginfo] target(s) in 2.20s
     Running `target/debug/git-cliff`
 WARN  git_cliff > "cliff.toml" is not found, using the default configuration.
## [0.1.0-beta.2] - 2021-06-14

### Bug Fixes

- Install musl-tools for musl builds

### Miscellaneous Tasks

- Update config

<!-- generated by git-cliff -->

$ # After
$ git checkout fix-skip-tags-behavior
$ cargo run | grep -A 20 "0.1.0-beta.2"
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/git-cliff`
 WARN  git_cliff > "cliff.toml" is not found, using the default configuration.
## [0.1.0-beta.2] - 2021-06-14

### Bug Fixes

- Add timestamp field to Release structs
- Update tests about recent changes
- Update fields
- Require -u or -l flag for prepending changelog
- Write to the given file for prepend operation
- Install zlib dependency
- Install musl-tools for musl builds

### Documentation

- Add doc comment to GroupParser
- Add comments
- Add FUNDING.yml
- Add comments to struct fields
- Add doc comment to generate method
- Add comments to main
- Mention docker

Describe alternatives you've considered

Seeing your use case, it seems you'd like to drop commits before v0.1.0-beta.1, which has a lot of commits.
Therefore, I guess it's nice to add another option like skip_before or so.

Additional context

Since we can drop commits by setting skip = true in commit_parsers, I guess there is no problem with changing like this.

Add support for interpreting footers and turning them into links

Is your feature request related to a problem? Please describe.
We use conventinal commits and make use of footers to link to external systems.

It would be nice to have the possibility to proccess these footers and transform them into links.
These links can then be included in the changelog entry so that readers of the changelog can just click them
to get to the linked item.

Given the following example commit:

fix(db): use correct schema relation

Detailed decription...

Fixes: #123
Fixes: workitem 456
Refs: RFC1234

I would like to generate the following changelog entry:

• fix(db): use correct schema relation (#123, workitem 456, RFC1234)

Describe the solution you'd like
I think the most flexible way would be to have an additional custom tera filters available that can be applied to each footer value during template processing.

 {% for footer in footers %}
         {{ footer | into_links }}
 {% endfor %}

The behaviour of into links would be configured in the config file as a series of replace patterns.

Describe alternatives you've considered
The following are alternatives I have tought off:

• A regex_replace in tera, as proposed in #14, could most probably solve the issue.
• Do a prost processing on the resulting changelog file and replace the URLs there.
• The possibility to define custom filters in the config would also work, but this would need som form os scripting language support.

Previous not populated when using --latest and skip_tags are set but don't match

Describe the bug
If skip_tags is defined with a regex that correctly generates the changelog (by skipping the correct/defined ones), there is a regression when setting previous and using --latest which was supposed to be fixed here: #3

But it looks like if you use --latest in combination with skip_tags, even if the pattern should not match the tag at all, it will simply not populate the previous field. This might have been introduced here(?): 7f867ae

If I remove the skip_tags from the config while generating with --latest, previous is populated as expected.

To Reproduce
Steps to reproduce the behavior:

[changelog]
header = """
# Changelog
All notable changes to this project will be documented in this file.\n
"""
body = """
{% if version %}\
    # [{{ version | trim_start_matches(pat="v") }}]\
    {% if previous %}\
        {% if previous.version %}\
            (https://github.com/discordjs/discord.js/compare/{{ previous.version }}...{{ version }})\
        {% else %}
            (https://github.com/discordjs/discord.js/tree/{{ version }}\
        {% endif %}\
    {% endif %} \
    - ({{ timestamp | date(format="%Y-%m-%d") }})
{% else %}\
    # [unreleased]
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
    ## {{ group | upper_first }}
    {% for commit in commits %}
        - {% if commit.breaking %}\
            [**breaking**] \
          {% endif %}\
            {% if commit.scope %}\
                **{{commit.scope}}:** \
            {% endif %}\
            {{ commit.message | upper_first }} ([{{ commit.id | truncate(length=7, end="") }}](https://github.com/discordjs/discord.js/commit/{{ commit.id }}))\
    {% endfor %}
{% endfor %}\n
"""
trim = true
footer = ""

[git]
conventional_commits = true
filter_unconventional = true
tag_pattern = "[0-9]*"
skip_tags = "v[0-9]*|11|12"
ignore_tags = ""

All tags on the repo in question:

10.0.0
10.0.1
11.0.0
11.1.0
11.2.0
11.3.0
11.3.1
11.3.2
11.4.0
11.4.1
11.4.2
11.5.0
11.5.1
11.6.0
11.6.1
11.6.2
11.6.3
11.6.4
12.0.0
12.0.1
12.0.2
12.1.0
12.1.1
12.2.0
12.3.0
12.3.1
12.4.0
12.4.1
12.5.0
12.5.1
12.5.2
12.5.3
13.0.0
13.0.1
13.1.0
13.2.0
13.3.0
13.3.1
13.4.0
13.5.0
5.2.0
5.3.2
6.0.0
6.1.0
7.0.0
7.0.1
8.0.0
8.1.0
8.2.0
9.0.2
9.1.0
9.1.1
9.2.0
9.3.0
9.3.1
v5.0.0
v5.0.1
v5.1.0
v5.3.0
v5.3.1

Expected behavior
Expect skip_tags to not drop unrelated tags from the previous field.

System (please complete the following information):

• OS Information: [Windows 11 Pro / 10.0.22000 Build 22000]
• Project Version: [0.5.0]

`sort_commits` doesn't work but `--sort` does

Describe the bug
I want my commits to be sorted by the newest time. However, it does not work using sort_commits = "newest" but it works using --sort newest

To Reproduce
Steps to reproduce the behavior:

1. git clone https://github.com/orhun/git-cliff
2. cd git-cliff
3. git-cliff --config config/cliff.toml --tag 0.1.0-beta.3

4. change sort_commits = "oldest" to sort_commits = "newest" in /git-cliff/config/cliff.toml
   the run the same command git-cliff --config config/cliff.toml --tag 0.1.0-beta.3

The order is same. no chages

---

5. Now, remove the sort_commits = "newest" line the config.
6. run git-cliff --config config/cliff.toml --tag 0.1.0-beta.3 --sort newest and git-cliff --config config/cliff.toml --tag 0.1.0-beta.3 --sort oldest. Now it works.
7. Got the error?

Expected behavior
sort_commits = "newest" should output the same exact thing as --sort newest

Screenshots/Logs
Attached.

System (please complete the following information):

❯ git-cliff --version
git-cliff 0.4.2, version: https://github.com/orhun/git-cliff/commit/02a6187a58583f27e4604d7ea518b52b4bc7a833

OS: Debian GNU/Linux 11 (bullseye)
Kernel: Linux 5.10.0-9-amd64 x86_64

Additional context
Thanks for git-cliff.

Global configuration file and builtin configuration

Hi, git-cliff is cool stuff!

1. Is your feature request related to a problem? Please describe.
I'd like to not put cliff.toml in my repository when I use git-cliff just as an alternative to git log.

2. Describe the solution you'd like
git-cliff locates cliff.toml in ~/.config/git-cliff/cliff.toml. If no configuraiton file is found, git-cliff uses default (builtin) configuration.

3. Describe alternatives you've considered
git-cliff looks into GIT_CLIF_CONFIG environment variable.

4. Additional context
Default configuration removes the need of copying cliff.toml, so it would help first-time users.

Does not work with conventional Pull Request commit messages without body

Describe the bug
Fails to parse conventional commit messages made from squashing and merging Pull Requests if there is no body message.

To Reproduce
Steps to reproduce the behavior:

1. Squash and merge a pull request (using conventional commits), without adding a body message
2. Try to create a changelog using extra verbose option
3. See the TRACE messages and the missing commits from the changelog

Expected behavior
These PR commit messages can be parsed as normal

Screenshots/Logs
I did these steps on a fork of this repo: https://github.com/mjhipp/git-cliff

Created pull requests, and merged them:

one of them I added an extra message:

The git log:

Then tried to create a changelog:

It is not the parenthesis or #, because it works if I commit directly:

If I perform an interactive rebase and "reword" the commits, without actually changing anything, the commits can then be parsed:

System (please complete the following information):

• OS Information: MacOS and ubuntu-latest for git-cliff-action
• Project Version: 0.1.0 and git-cliff-action@v1

Additional context
Sorry for the long post! This is a great tool and I would really like to be able to use it with squashed PRs!

Gitlab CI, git-cliff is working on v0.4.0, git repo is set, config file is here but no changelog ...

Describe the bug
I set the Gitlab CI with the following stage

changelog:
  image:
    name: orhunp/git-cliff:latest
    entrypoint: [""]
  stage: doc
  script:
    - git-cliff

here is the result on Gitlab CI

here on local

I don't understand why it is not working.
I try to reproduce the error but impossible on a new repo :/
If you have any idea where it can come from

System (please complete the following information):

• OS Information: Ubuntu (but this part is working fine) & Gitlab CI
• Project Version: 0.4.0

The `--current` option involves the release notes of other tags

Describe the bug

When the commit-graph is like the following, the --current option doesn't work correctly.

The tags variable was like this.

However, the current code uses current_tag_index - 1 for the previous tag.

git-cliff/git-cliff/src/lib.rs

Line 169 in 848d8a5

tag_index = current_tag_index - 1;

I think we should find the nearest parent tag here.

To Reproduce

I attached my test scripts and the output.
Please save this script and run it.

test script

#!/bin/bash
set -e

# Set up repository
rm -rf /tmp/test
mkdir -p /tmp/test
cd /tmp/test
git init
git commit --allow-empty -m "Initial commit"

# Create tags
git commit --allow-empty -m "feat: v0.1.0"
git tag v0.1.0
sleep 1

git checkout v0.1.0
git commit --allow-empty -m "feat: v0.2.0"
git tag v0.2.0
sleep 1

git checkout v0.1.0
git commit --allow-empty -m "fix: v0.1.1"
git tag v0.1.1
sleep 1

git checkout v0.2.0
git commit --allow-empty -m "feat: v0.3.0"
git tag v0.3.0
sleep 1

# Show results
git checkout v0.1.0
echo "------"
echo "v0.1.0"
git-cliff --current
echo "------"

git checkout v0.1.1
echo "------"
echo "v0.1.1"
git-cliff --current
echo "------"

git checkout v0.2.0
echo "------"
echo "v0.2.0"
git-cliff --current
echo "------"

git checkout v0.3.0
echo "------"
echo "v0.3.0"
git-cliff --current
echo "------"

Without sleep, probably because the commit timestamp will be the same and it won't reproduce the problem.

output

$ ./test.sh
Initialized empty Git repository in /tmp/test/.git/
[main (root-commit) 228dbab] Initial commit
[main 7d5b9fb] feat: v0.1.0
Note: switching to 'v0.1.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 7d5b9fb feat: v0.1.0
[detached HEAD ee77516] feat: v0.2.0
Previous HEAD position was ee77516 feat: v0.2.0
HEAD is now at 7d5b9fb feat: v0.1.0
[detached HEAD 44cfc20] fix: v0.1.1
Previous HEAD position was 44cfc20 fix: v0.1.1
HEAD is now at ee77516 feat: v0.2.0
[detached HEAD 567de7b] feat: v0.3.0
Previous HEAD position was 567de7b feat: v0.3.0
HEAD is now at 7d5b9fb feat: v0.1.0
------
v0.1.0
 WARN  git_cliff > "cliff.toml" is not found, using the default configuration.
# Changelog
All notable changes to this project will be documented in this file.

## [0.1.0] - 2022-01-30

### Features

- V0.1.0

<!-- generated by git-cliff -->
------
Previous HEAD position was 7d5b9fb feat: v0.1.0
HEAD is now at 44cfc20 fix: v0.1.1
------
v0.1.1
 WARN  git_cliff > "cliff.toml" is not found, using the default configuration.
# Changelog
All notable changes to this project will be documented in this file.

## [0.1.1] - 2022-01-30

### Bug Fixes

- V0.1.1

<!-- generated by git-cliff -->
------
Previous HEAD position was 44cfc20 fix: v0.1.1
HEAD is now at ee77516 feat: v0.2.0
------
v0.2.0
 WARN  git_cliff > "cliff.toml" is not found, using the default configuration.
# Changelog
All notable changes to this project will be documented in this file.

## [0.2.0] - 2022-01-30

### Features

- V0.2.0

<!-- generated by git-cliff -->
------
Previous HEAD position was ee77516 feat: v0.2.0
HEAD is now at 567de7b feat: v0.3.0
------
v0.3.0
 WARN  git_cliff > "cliff.toml" is not found, using the default configuration.
# Changelog
All notable changes to this project will be documented in this file.

## [0.3.0] - 2022-01-30

### Features

- V0.3.0

## [0.2.0] - 2022-01-30

### Features

- V0.2.0

<!-- generated by git-cliff -->
------

0.2.0 is included in 0.3.0.

## [0.3.0] - 2022-01-30

### Features

- V0.3.0

## [0.2.0] - 2022-01-30

### Features

- V0.2.0

Expected behavior

The output only includes the tag's changes.

In this case:

## [0.3.0] - 2022-01-30

### Features

- V0.3.0