Minor versions that exceed x.x.10 incorrectly output when using --current flag

[tlackemann]

Describe the bug

When using tags such as v0.1.8 and v0.1.9, version notes are correctly output when using the --current flag. However, when the tag is v0.1.10, the changelog will include all notes when using the --current flag, not just the current tag.

To Reproduce
Steps to reproduce the behavior:

1. Create commit
2. Tag v0.1.9
3. git-cliff --current outputs correct changelog
4. Create new commit
5. Tag v0.1.10
6. git-cliff --current outputs both v0.1.9 and v0.1.10

Expected behavior
Only v0.1.10 release notes are displayed.

Screenshots/Logs
If applicable, add screenshots to help explain your problem.

System (please complete the following information):

• OS Information: Linux x86_64
• Project Version: 0.9.2

Additional context
Add any other context about the problem here.

[bu6n]

Having the same problem with the --latest flag, so not sure this is because of the flag. I'm willing to open a PR, but haven't found the related code yet. @orhun can you show me where to look at?

[orhun]

It turns out there is actually an integer overflow on this line when current_tag_index is 0:

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

Line 205 in 0c7769b

tag_index = current_tag_index - 1;

thread 'main' panicked at 'attempt to subtract with overflow', git-cliff/src/lib.rs:208:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

But it is implicit because release profile sets overflow-checks to false. You only can see it if you build for debug profile i.e. cargo build without --release.

Now onto the actual problem: git-cliff sorts the tags topologically (see #58) thus e.g. when you have v0.0.10 and v0.0.9 they are sorted as v0.0.10-v0.0.9 and this triggers the bug which is explained above (since current_tag_index is 0). Plus there is no overflow check so you seem to experience some strange behavior with release builds instead of seeing the overflow error.

As a solution, you should use --date-order with your command. I pushed e73fd9f for warning about this. Also made it possible to specify date order via -d in 5913e24

I hope this helps 🐻

[orhun]

With the upcoming release, --date-order will be the default and that flag will be removed. See #126

This is a breaking change so I thought I'd make this clear beforehand 🐻

[kenji-miyake]

FYI @orhun: I did some investigation with @shmpwk.

• The order of repo.tag_names isn't topological (seems to be alphabetical): https://github.com/rust-lang/git2-rs/blob/3df7e810857184194e4d02898d033cc14957a2f1/examples/tag.rs#L67
  • Seems to refer the bottom of .git/packed-refs. (You can check this behavior by removing some lines in the file.)
• git-cliff seems to use the order as it is:

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

  Lines 109 to 123 in 0e710c2

  	let tag_names = self.inner.tag_names(pattern.as_deref())?;
  	for name in tag_names.iter().flatten().map(String::from) {
  	let obj = self.inner.revparse_single(&name)?;
  	if let Ok(commit) = obj.clone().into_commit() {
  	tags.push((commit, name));
  	} else if let Some(tag) = obj.as_tag() {
  	if let Some(commit) = tag
  	.target()
  	.ok()
  	.and_then(|target| target.into_commit().ok())
  	{
  	tags.push((commit, name));
  	}
  	}
  	}

How to reproduce

$ cd /tmp
$ git clone https://github.com/rust-lang/git2-rs
$ cd git2-rs
$ cargo build --examples

$ cd ../
$ git clone https://github.com/autowarefoundation/autoware-github-actions.git
$ cd autoware-github-actions
$ ../git2-rs/target/debug/examples/tag --list
v1
v1.0.0
v1.1.0
v1.1.1
v1.10.0
v1.10.1
v1.11.0
v1.11.1
v1.12.0
v1.13.0
v1.14.0
v1.15.0
v1.15.1
v1.15.2
v1.16.0
v1.16.1
v1.17.0
v1.18.0
v1.19.0
v1.2.0
v1.20.0
v1.21.0
v1.21.1
v1.22.0
v1.23.0
v1.24.0
v1.25.0
v1.25.1
v1.25.2
v1.25.3
v1.25.4
v1.3.0
v1.3.1
v1.3.2
v1.3.3
v1.3.4
v1.3.5
v1.4.0
v1.5.0
v1.6.0
v1.6.1
v1.7.0
v1.7.1
v1.8.0
v1.8.1
v1.8.2
v1.8.3
v1.9.0

[kenji-miyake]

@orhun Do you know whether git2-rs has a way to get topologically-sorted tags? Or can we manually sort the order using revwalk or something after getting all tags by self.inner.tag_names?

[kenji-miyake]

FYI: Also, I'll leave a note for future reference.
If you add a tag locally after cloning the repository, the order may be weird, which causes the following error.

$ git cliff --current --topo-order
...
 ERROR git_cliff > Changelog error: `No suitable tags found. Maybe run with '--topo-order'?`

This is because the new local tag isn't listed in .git/packed-refs yet.
git gc can solve the issue.

❯ git tag v1.1.2

❯ ../git2-rs/target/debug/examples/tag --list | head
v1.1.2
v1
v1.0.0
v1.1.0
v1.1.1

❯ git gc

❯ ../git2-rs/target/debug/examples/tag --list | head
v1
v1.0.0
v1.1.0
v1.1.1
v1.1.2

On GitHub Actions, this won't happen because the repository is cloned with /usr/bin/git config --local gc.auto 0.