Support processing the commits starting from a specific tag

[landerss1]

Is there an existing issue or pull request for this?

• I have searched the existing issues and pull requests

Feature description

Currently, there's support for processing commits starting from the current or latest tag, or commits without any tag, but not starting from a specific tag. This would make the transition from unconventional commits to conventional commits much smoother. Then, you could keep the old changelog as, e.g. HISTORY.md, and then start a new CHANGELOG.md based on commits after a specific tag.

Desired solution

Introduce a new command-line argument that can be used to specify the tag that should be used to start fetching commits from.

Alternatives considered

Can't think of any.

Additional context

No response

[welcome]

Thanks for opening your first issue at git-cliff! Be sure to follow the issue template! ⛰️

[orhun]

Hello!

Have you tried the git range option?

e.g.

git cliff v0.1.0..HEAD

Or even more shorter:

git cliff v2.2.1..

Other examples:

git cliff 4c7b043..a440c6e
git cliff 4c7b043..HEAD
git cliff HEAD~2..

I think this is what you are looking for :)

[landerss1]

Ah, Thanks. I saw the range CLI argument in the docs, but there was no description or examples. I have tried it now, and it solves my problem, but you have to go one tag further back than expected, so you have to specify range start=<desired-tag>-1. Is this what's to be expected?

[orhun]

I think yes, since git ranges work like that. It is handled by the underlying git library (git2).

I expanded the examples in d451252

[lermontex]

@orhun, as far as I understand, git ranges will conflict with the --unreleased, --latest, etc. flags, so git ranges is not entirely suitable, since it will not allow flexible configuration

It would be great if it was possible to specify the tag from which to start the story

There is an initial_tag parameter in the configuration, maybe it’s worth using it?

https://git-cliff.org/docs/configuration/bump/#initial_tag

[orhun]

as far as I understand, git ranges will conflict with the --unreleased, --latest, etc. flags, so git ranges is not entirely suitable, since it will not allow flexible configuration

Yeah, using those flags will override the commit range.

Can you give me an example case (i.e. git history) to make this matter more clear? I'm happy to implement it as long as we have the correct behavior with test fixtures in place.

There is an initial_tag parameter in the configuration, maybe it’s worth using it?

initial_tag option is related to the bump configuration and I don't think it is suitable for this case.