Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange behaviour with "parallel" codelines #29

Closed
arthrarnld opened this issue Oct 22, 2021 · 1 comment
Closed

Strange behaviour with "parallel" codelines #29

arthrarnld opened this issue Oct 22, 2021 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@arthrarnld
Copy link

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

@arthrarnld arthrarnld added the bug Something isn't working label Oct 22, 2021
@orhun
Copy link
Owner

orhun commented Oct 29, 2021

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 000a67c. And this can be made easily opt-out with an extra flag.

That's why I added --topo-order flag in cc09d63 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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants