Add an option for processing only the current tag

[kenji-miyake]

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.

[orhun]

Hey, thanks for reporting this!

I implemented the --current flag in 02a6187, it behaves exactly the same as you described:

$ git checkout v0.11.0-test

$ git cliff

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

## [0.11.0-test] - 2021-12-01

### Features

- Add B

## [0.10.0-test] - 2021-12-01

### Features

- Add A

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

$ git cliff --latest

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

## [0.10.1-test] - 2021-12-01

### Bug Fixes

- Fix A

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

Most importantly:

$ git cliff --current

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

## [0.11.0-test] - 2021-12-01

### Features

- Add B

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

Underlying logic is basically running the following command and processing its result (current tag) starting from the previous tag.

$ git describe --tags $(git rev-parse HEAD)

Thus, if you don't have any tags associated with HEAD, --current fails, as expected:

$ git describe --tags $(git rev-parse HEAD)
v0.4.2-9-g02a6187 # current tag + revision = not a "real" tag

$ git cliff --current
 ERROR git_cliff > Changelog error: `No tag exists for the current commit`

Feel free to try it out and let me know if it works as you expected 🐻

[kenji-miyake]

@orhun Wow, cool! It seems working well.
Thank you very much! 🐻