-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
🌱 Improve multiple areas PRs with user friendly subs #9071
🌱 Improve multiple areas PRs with user friendly subs #9071
Conversation
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.
/retest
1c307da
to
e182064
Compare
/retest |
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.
Looks good to me excepting the sorting change.
This applies the same user friendly areas substitutions to the multiple areas entries that it was already applied to single area entries. As a bonus, add a case insensitive string sorting that avoids exponential string allocation.
e182064
to
333b213
Compare
/lgtm |
LGTM label has been added. Git tree hash: cd019b9c1747c9f94a5409255a31f35fa923455f
|
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
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: killianmuldoon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What this PR does / why we need it:
This applies the same user friendly areas substitutions to the multiple areas entries that it was already applied to single area entries.
As a bonus, add a case insensitive string sorting that avoids exponential string allocation. There was no major issue with the previous implementation, I just already had this one lying around and it should be a bit more efficient. This is mostly because strings are immutable in Go, so any
ToLower
call would basically have to allocate memory for a new string.Which issue(s) this PR fixes:
Part of #9008
/area release