-
-
Notifications
You must be signed in to change notification settings - Fork 264
feat(git): disable sorting commits topologically (#804) #1121
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
Conversation
|
Thanks for opening this pull request! Please check out our contributing guidelines! ⛰️ |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1121 +/- ##
==========================================
- Coverage 41.58% 41.48% -0.10%
==========================================
Files 21 21
Lines 1816 1823 +7
==========================================
+ Hits 755 756 +1
- Misses 1061 1067 +6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
114673f to
30baa95
Compare
orhun
left a comment
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 the PR! This is definitely one of the crucial missing pieces so I appreciate you taking time to implement it.
Some comments:
- I think the option should be called
topo_order_commits.disable_topo_order_commitsdoes not read well since we are using a boolean. (e.g. disable disable_topo_order_commits) - We already have a
topo_orderoption for sorting the tags. I think we should rename that totopo_order_tagsand deprecate the old option. What do you think? (cc. @Cyclonit since he worked on revamping the config before) - We should add fixture tests for this, see the instructions here.
|
I would propose refactoring the system to have two options:
Having enums instead of booleans improves readability significantly. But I know @orhun likes using as few words as possible ;) However, we do not have any way of soft deprecating old config options and adding new ones beside it. That is something that would have to be designed. |
3f7f698 to
bd21beb
Compare
In that case we also need to deprecate the old options. I'd prefer we go with
We can probably add a warning while parsing the config 🤔 I'll look into it. LMK @SebClapie when this is ready for review. |
|
Hello @orhun , I updated the code to rename the option |
The git update-index --chmod=+x <file> |
9020f27 to
12d4778
Compare
641e0f0 to
1dab65b
Compare
|
The Typos action failed. But I don't think it's linked to my modification |
orhun
left a comment
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.
LGTM, some minor comment issues :)
Can you also create a new issue for tracking the deprecation of topo_order (in favor of topo_order_tags)?
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
orhun
left a comment
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.
Some styling suggestions
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
orhun
left a comment
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.
Some minor things left :)
- The fixture config can be simplified.
- A small tweak in docs is needed (see my comment)
- We need an issue to track the deprecation of config
Hello @orhun |
The current config schema has grown historically and is in need of a refactor. I attempted to do this back in #541, but couldn't keep up with other changes at the time. The goal of improving the config in general remains though. One of the requirements for overhauling the config is the ability to soft deprecate old options. Otherwise any change to the config would be an immediate breaking change. I don't think you need to care about that right now. |
orhun
left a comment
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.
LGTM, thanks!
We'll probably talk about the deprecation of some options during the config revamp, which should be git-cliff v3 eventually.
|
Congrats on merging your first pull request! ⛰️ |
Description
Add sorting option for commits
Motivation and Context
This change is related to #804
When I tried git-cliff on my personal git repository, the commits order was not correct.
I finally found why the order was not correct. The CHANGELOD generated got the same order than the command git log --oneline --topo-order.
How Has This Been Tested?
I did not add a specific test for this feature, I apologize, I just installed rust for the first time yesterday and I never used GitHub before ..
I tried to follow your recommandation.
I launched:
I also tested on my side that the sort is functional on my repro. I tested the command line option --disable-topo-order-commits
I also tested this option inside my file cliff.toml
Screenshots / Logs (if applicable)
Types of Changes
Checklist:
I launched cargo fmt and cargo clippy
Maybe the text can be improved