search

github-changelog-generator / github-changelog-generator

Automatically generate change log from your tags, issues, labels and pull requests on GitHub.
MIT License
7.37k stars 847 forks source link

Multiple tags/releases on the same date do not sort in order #244

Closed ryanwalls closed 9 years ago

ryanwalls commented 9 years ago

If I create multiple tags on the same day, in the changelog the tags are sorted in ascending order. I would expect them to sort in descending order.

Here's what is generated currently (this is a private repo, but you get the idea):

# Change Log

## [v0.1.57](https://github.com/3DSIM/login/tree/v0.1.57) (2015-06-03)

[Full Changelog](https://github.com/3DSIM/login/compare/v0.1.59...v0.1.57)

## [v0.1.59](https://github.com/3DSIM/login/tree/v0.1.59) (2015-06-03)

[Full Changelog](https://github.com/3DSIM/login/compare/v0.1.60...v0.1.59)

## [v0.1.60](https://github.com/3DSIM/login/tree/v0.1.60) (2015-06-03)

[Full Changelog](https://github.com/3DSIM/login/compare/v0.1.65...v0.1.60)

## [v0.1.65](https://github.com/3DSIM/login/tree/v0.1.65) (2015-06-03)
skywinder commented 9 years ago

The tags sorted in order, how they appear in your git repo. Are you sure, that 0.1.65 is older than 0.1.57?

please check it by command:

git log --tags --simplify-by-decoration --pretty="format:%ai %d"
ryanwalls commented 9 years ago

I would expect the tags to sort in reverse order (newest tag first) just like it does on the releases page.

image

skywinder commented 9 years ago

Ok. It should be in that order. Ok, I will check it!

skywinder commented 9 years ago

@ryanwalls Hi. I check sorting method, and also add some tests for it, but can't reproduce your bug. All tags sorted according date from the commits, that assigned to tags. Have no idea, why it messed up in your case. It will be nice if you can reproduce it on some public repo or add more details about your case.

ryanwalls commented 9 years ago

@skywinder Thanks for checking. I'll try to see if I can recreate in a public repo. But it's probably not a critical bug. Seems to only happen with tags on the same day. Most of the time, my tags will be on different days anyway.

skywinder commented 9 years ago

@ryanwalls that's strange. The time from github api looks like "2015-03-04T17:10:16Z" And it's stored and sorted as Time class, parsed from string: https://github.com/skywinder/github-changelog-generator/blob/master/lib/github_changelog_generator/fetcher.rb#L200 So, it doesn't matter is tag created one second or one day later.

Let's investigate this problem. As soon as I can reproduce it - I will fix it.

skywinder commented 9 years ago

@ryanwalls any updates with this behaviour? Still try to reproduce it, but have no luck.

skywinder commented 9 years ago

@ryanwalls Since there is only one time that this bug occurs and there is no way to reproduce it, I close it. Let me know, if you find any additional info.

sbrown-nw commented 8 years ago

We reproduced this in one of our Infospace private repos:

https://github.com/infospace/search_clientside_results/releases

Expect the 3.9.1.508 release tag to be most recent (by publish time and tag version) instead of the 3.9.0.507 one.

skywinder commented 8 years ago

@sbrownInfospace your link doesn't work, since repo is private. I would like to debug this bug, but need real example.

nathanwebsterdotme commented 7 years ago

Hi, I'm also experiencing this issue when using the API to create tags via the releases API calls.

binhex commented 7 years ago

any news on this?, its now 2017 and the github api still sorts tags incorrectly, or at least it looks like it sorts based on numeric value of the tag rather than the more logical sorting of when created.

nuno-agostinho commented 7 years ago

Good evening! I am also experiencing inconsistent order from releases tagged in the same day: https://github.com/nuno-agostinho/psichomics/releases

EDIT: I fixed this by editing the tag from the version number alone to alphanumeric (e.g. changing some tags from 1.1.10 to v1.1.10).

julienmoumne commented 7 years ago

Reproducible issue on https://github.com/piwik/piwik-dotnet-tracker

We use this configuration file.

Here is the produced markdown. It would be nice to have 1.9.2 before 1.9.1, especially since the changelog links are not correct :

tags-in-wrong-order

Here is the result of git log --tags --simplify-by-decoration --pretty="format:%ai %d" :

git-log-tags-pretty

This is the first time I have an issue with this tool. I am using it on several projects and it has saved me a lot of time managing changelogs.

It was working a couple of weeks ago on darwin. The results I am reporting here are on WSL, v1.14.3, Ruby 2.4.0p0

rkpatel33 commented 6 years ago

Getting the same error when creating a release for an Electron project using electron-builder. Unfortunately this a private repo and I can't share it, but its created using the github API.

image

mattfidler commented 6 years ago

I am getting similar issues here:

https://github.com/nlmixrdevelopment/nlmixr/releases

It is a public repo; I tried adding/editing tags but it just cluttered it further.

ernestostifano commented 4 years ago

This issue is still present today...

developerark commented 4 years ago

I have the same issue. Here is a screenshot. v1.1.0 should be above v1.0.0.

Screen Shot 2020-07-17 at 1 13 34 PM

ernestostifano commented 4 years ago

Hi everyone! I think I have some kind of solution. At least I've managed to order tags/releases at will.

There are two things to keep in mind:

With that being said, my solution was to use the following bash command (inspired from comments of this StackOverflow answer) to change tags dates as needed:

git tag -l | while read -r tag ; do COMMIT_HASH=$(git rev-list -1 $tag) && NEW_DATE=$(git show $COMMIT_HASH --format=%aD | head -1) && GIT_AUTHOR_DATE="$NEW_DATE" GIT_COMMITTER_DATE="$NEW_DATE" GIT_TAGGER_DATE="$NEW_DATE" git tag -a -f $tag -m"$tag" $COMMIT_HASH ; done && git push --tags --force

This will loop through all the tags and set GIT_TAGGER_DATE, GIT_AUTHOR_DATE and GIT_COMMITTER_DATE equal to the original tag Author Date. Then it will force update upstream tags.

If you want to filter tags for this operations, use git tag -l \<pattern>.

If you want to use a custom date, change NEW_DATE variable accordingly. Use Thu, 23 Apr 2020 01:38:28 +0200 like format.

You might have to try some different dates/times combinations to get the desired order.

Auzzy commented 4 years ago

@ernestostifano Just tried your command after hitting this issue myself, and it worked beautifully. Thanks!

bmaupin commented 3 years ago

The fix from @ernestostifano worked great for me, although I found the explanation to be partially inaccurate, in particular this part:

It seems GitHub uses GIT_TAGGER_DATE to determine order in the releases/tags console. Not GIT_AUTHOR_DATE nor GIT_COMMITTER_DATE.

At least in my case, GitHub was sorting my tags by creator date:

$ git tag -l --sort=-creatordate --format='%(creatordate:short):  %(refname:short)'
2021-06-18:  v0.6
2021-06-14:  v0.6.1
2019-08-19:  v0.5.3
2019-08-14:  v0.5.2

I had created v0.6 myself using git tag, whereas the other tags I'd created on the GitHub site.

For comparison, here are the tags sorted by tagger date, which looks correct:

$ git tag -l --format='%(refname)   %(taggerdate)'
refs/tags/v0.5.2   
refs/tags/v0.5.3   
refs/tags/v0.6   Fri Jun 18 14:48:01 2021 -0400
refs/tags/v0.6.1

After running the command provided by @ernestostifano, the tags are now sorted properly by creator date:

$ git tag -l --sort=-creatordate --format='%(creatordate:short):  %(refname:short)'
2021-06-14:  v0.6.1
2021-06-11:  v0.6
2019-08-19:  v0.5.3
2019-08-14:  v0.5.2

And after doing the git push --force --tags, they're properly sorted in GitHub as well.

Thanks!

Enduriel commented 3 years ago

I'm unable to fix this with the script provided by @ernestostifano, and honestly it's somewhat ridiculous that this is still a thing at all. Private repo as well unfortunately, but the below screenshot shows the hilarity of the situation. image

jlacivita commented 1 year ago

FWIW, we are seeing the same:

https://github.com/rdkcentral/firebolt-core-sdk/tags

the tag for v0.11.0-next.1 was created after v0.11.0-one-repository.1 through v0.11.0-one-repository.10 but it shows up after them in the list (currently on page two).

We definitely had a few minutes where we thought our CI was failing to tag the release, but then I saw the tag (sorted correctly) in my GitHub Desktop client, and went looking for it.