orhun / git-cliff

A highly customizable Changelog Generator that follows Conventional Commit specifications ⛰️
https://git-cliff.org
Apache License 2.0
9.25k stars 198 forks source link

Strange behaviour with "parallel" codelines #29

Closed arthrarnld closed 2 years ago

arthrarnld commented 3 years ago

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! 🤗

orhun commented 3 years ago

Hello! Thanks for reporting this.

I can say that this is not the indented behaviour for this case. Using -u should not include any tagged commits in the changelog.

I created the following commit history for reproducing this issue:

* f95ee65 (tag: v0.1.1, fix_v1) fix: patch on v0.1.x
| * 709faef (HEAD -> master) feat: fifth commit on master
| * 8da0f06 (tag: v0.2.0) feat: fourth commit on master
| * 527cefd chore: third commit on master
|/  
* a9f6323 (tag: v0.1.0) fix: second commit on master
* 2c9cadb feat: first commit on master

When -u is specified, git-cliff implicitly uses the following portion of the commit history:

f95ee65..HEAD

So it creates this changelog:

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

## [unreleased]

### Features

- Fifth commit on master

## [0.2.0] - 2021-10-29

### Features

- Fourth commit on master

### Miscellaneous Tasks

- Third commit on master

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

Chronologically, this is correct because f95ee65 is the last tagged commit:

  1. v0.1.1 (f95ee65) -> latest
  2. v0.2.0 (8da0f06)
  3. v0.1.0 (a9f6323)

But from the practical standpoint, doing this will obviously include the previously tagged commits. So for your use case, tags should be used by their "appearance order" in the commit history. Like this:

  1. v0.2.0 (8da0f06) -> latest
  2. v0.1.1 (f95ee65)
  3. v0.1.0 (a9f6323)

While searching for the roots of this issue, I realized this happens due to 000a67cd8aae7ae20848baa04cd6212376dcde12. And this can be made easily opt-out with an extra flag.

That's why I added --topo-order flag in cc09d637ff4edfcba625e469dcd3eb0062ac2a4f which sorts the tags in topological order (children before parents). I believe this flag will be useful for similar scenarios as well.

So now git cliff --unreleased --topo-order will give you the expected result:

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

## [unreleased]

### Features

- Fifth commit on master

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

Lastly, this flag will be available in the upcoming release so feel free to try it out and report bugs by either pulling the docker image or building from source.

Let me know if you have any questions/suggestions/ideas 🐻

(PS: Sorry for the late reply, I've been dealing with a job change + school stuff)