Handle too long PR titles correctly #16517
No reviewers
Labels
No Label
backport/done
backport/v1.0
backport/v1.1
backport/v1.10
backport/v1.11
backport/v1.12
backport/v1.13
backport/v1.14
backport/v1.15
backport/v1.2
backport/v1.3
backport/v1.4
backport/v1.5
backport/v1.6
backport/v1.7
backport/v1.8
backport/v1.9
bounty
changelog
dependencies
frontport/done
frontport/main
good first issue
Hacktoberfest
hacktoberfest-accepted
in progress
kind/api
kind/breaking
kind/bug
kind/build
kind/deployment
kind/deprecated
kind/docs
kind/enhancement
kind/feature
kind/lint
kind/misc
kind/moderation
kind/package
kind/proposal
kind/question
kind/refactor
kind/regression
kind/security
kind/summary
kind/testing
kind/translation
kind/ui
kind/upstream-related
kind/usability
kind/ux
lgtm/done
lgtm/need 1
lgtm/need 2
performance/bigrepo
performance/cpu
performance/memory
performance/speed
priority/critical
priority/low
priority/maybe
priority/medium
proposal/rejected
reviewed/confirmed
reviewed/duplicate
reviewed/fixed
reviewed/invalid
reviewed/not-a-bug
reviewed/wontfix
skip-changelog
stale
status/blocked
status/needs-feedback
status/wip
theme/2fa
theme/authentication
theme/avatar
theme/backup-restore
theme/docker
theme/federation
theme/issues
theme/kanban
theme/markdown
theme/migration
theme/mobile
theme/pr
theme/signing
theme/sqlite
theme/timetracker
theme/webhook
theme/wiki
No Milestone
No project
No Assignees
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: lunny/gitea#16517
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "fix-16507-long-commit-messages"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The CompareAndPullRequestPost handler for POST to /compare
incorrectly handles returning errors to the user. For a start
it does not set the necessary markers to switch SimpleMDE
but it also does not immediately return to the form.
This PR fixes this by setting the appropriate values, fixing
the templates and preventing the suggestion of a too long
title.
Fix #16507
Signed-off-by: Andrew Thornton art27@cantab.net
Could use Unicode character instead of "..." and use 254 characters for title
So I initially considered that but remembered - perhaps incorrectly - that github doesn't use …
U+2026
for some reason itself.We use in all UI parts it already, on other hand this will go to database so idk ?
I mean if we're willing to risk the mysql and mssql users' wrath and/or people who insist on non utf8 in their commit logs then switching to use ellipsis instead would be easy.
I don't understand this to be honest ?... Not that there is still software that does not support utf8
Anyway this was just suggestion and is non blocking from my side
lets try the ellipsis.
same here should be changed then
This is still not correct because you have to consider utf8. Simply use
title[254:]
will break some of utf8 string.Yup looks like we'd need to cast to []rune and then drop the last rune.
Probably also need to consider if the last rune is a combining character too.
and we would need to consider this in chi-binding too.
I've switched the code to use byte length and truncation algorithm
@ -0,0 +14,4 @@
}
if !utf8.ValidString(input) {
left = input[:n-3] + "..."
ValidString
don't mean it's totally ascii. Maybe we should correct it.@ -0,0 +14,4 @@
}
if !utf8.ValidString(input) {
left = input[:n-3] + "..."
The test here is to simply abort trying to be nice if the string is not a valid utf8 string. (Which could be ASCII, Big5, UTF-16...)
If you don't have a utf-8 string in your commit header - getting it truncated nicely is going to be the least of your worries. We really don't handle other encodings in git commit headers.