doc(config): update comments for all configuration options

[Cyclonit]

Description

Updated the comments in all instances of config.toml and config.rs.

Motivation and Context

Some of the comments were unclear, had inconsistent punctation or wording.

How Has This Been Tested?

no functional changes

Screenshots / Logs (if applicable)

does not apply

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no code change)
• Refactor (refactoring production code)
• Other

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly.
• I have formatted the code with rustfmt.
• I checked the lints with clippy.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 41.85%. Comparing base (cd26bb2) to head (d10937c).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1057      +/-   ##
==========================================
- Coverage   41.90%   41.85%   -0.05%     
==========================================
  Files          21       21              
  Lines        1790     1790              
==========================================
- Hits          750      749       -1     
- Misses       1040     1041       +1     

Flag	Coverage Δ
unit-tests	41.85% <ø> (-0.05%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[orhun]

Thanks, great cleanup! 🎉

I had some comments, it would be nice to update the other occurrences based on those as well :)

[orhun]

Suggested change

	# Order releases topologically instead of chronologically.
	# Order tags topologically instead of chronologically.

[Cyclonit]

Why tags instead of releases? Doesn't it affect the release order? The description should reflect the options effect and not how it is implemented.

[orhun]

We are using this flag to sort the tags, which then affects the order of the releases.

git-cliff/git-cliff-core/src/repo.rs

Lines 421 to 423 in 5f3a3d0

	if !topo_order {
	tags.sort_by(|a, b| a.0.time().seconds().cmp(&b.0.time().seconds()));
	}

So I think using "tags" would be more correct here.

The description should reflect the options effect and not how it is implemented.

I think the user should be aware of tags vs releases when using a git automation tool like this.

[Cyclonit]

But a user wants to know how the config affects the final result. And there it affects the order of releases, by sorting the tags. The variable tags in your code reference could more accurately be referred to as release_tags. Because those tags represent releases. I am willing to be overruled, but these are my last two cents ;)

[orhun]

Suggested change

	# How to order commits in each group/release within the changelog.
	# allowed values: newest, oldest
	# Whether to order commits in each group/release by newest/oldest.

[Cyclonit]

I checked with others and they agreed that putting the options on a separate line makes them being the valid options easier to understand. What reason is there to keep in short?

[orhun]

It's not a big deal imo - I just didn't want to spend a whole line for explaining possible values for this option.

If we go with a new line, this might imply that we are following this format for the other options in the future.

[Cyclonit]

Would that not be a good idea?