-
-
Notifications
You must be signed in to change notification settings - Fork 199
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
fix(git): sort commits in topological order #415
Conversation
Commit a1b4b5b ("fix(git): sort the commits in topological order"), changed the order from `TIME` to `TIME | TOPOLOGICAL`. According to the docs, this is equivalent to `git log --date-sort`: * https://github.com/libgit2/libgit2/blob/v1.7.1/include/git2/revwalk.h#L33-L38 This breaks down in the following scenario: 1. A PR is open. 2. A release v1 is made. 3. A PR is merged. 4. A relase v2 is made. The git history for this would be: ``` - v2 release - pr merge commit - v1 release - actual pr commit ``` This directly spills into the changelog produced by `git-cliff`, misattributing commits that were merged in v2 to v1 retroactively when v2 is made. You can see this with `git log`. If you pass `--topo-order` there: ``` - v2 relase - pr merge commit - actual pr commit - v1 relase ``` With this change we only pass `Sort::TOPOLOGICAL` in `git-cliff`, which produces the very same results as `git log --topo-order`.
Thanks for opening this pull request! Please check out our contributing guidelines! ⛰️ |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #415 +/- ##
=======================================
Coverage 42.42% 42.42%
=======================================
Files 15 15
Lines 995 995
=======================================
Hits 422 422
Misses 573 573
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Before:
After:
Issues #188 and #38 indeed look like they would be fixed with this change. |
Oh yeah, that indeed looks correct.
That's awesome. They were open for a long time because I couldn't figure out what's going on. Have you reproduced the cases mentioned there? i.e. Are we confident to close them after this PR is merged? One last thing, I'm assuming there won't be cases where this breaks any uses cases, right? It should be changed anyways since it is the wrong behavior. Lastly, thanks for coming out of nowhere and fixing this! 🐻 |
I have not reproduced them, but they do look functionally identical. I'd be surprised if this change doesn't fix them.
I don't think anything would break here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution!
Congrats on merging your first pull request! ⛰️ |
closes #188
closes #38
Description
Commit a1b4b5b ("fix(git): sort the commits in topological order"), changed the order from
TIME
toTIME | TOPOLOGICAL
. According to the docs, this is equivalent togit log --date-sort
:This breaks down in the following scenario:
The git history for this would be:
This directly spills into the changelog produced by
git-cliff
, misattributing commits that were merged in v2 to v1 retroactively when v2 is made.You can see this with
git log
. If you pass--topo-order
there:With this change we only pass
Sort::TOPOLOGICAL
ingit-cliff
, which produces the very same results asgit log --topo-order
.How Has This Been Tested?
Tested on a repo with the scenario described above.
Screenshots / Logs (if applicable)
Here's the
git log
output that is causing commitZTC-886
to be misattributed to v2.0.6 when it was only merged after the release happened.Types of Changes
Checklist: