truncating first line of commit message too agressive

[nikodemus]

Currently when a PR is composed of a single commit, the first line of that commit becomes the PR title.

When the first line is longer than 72 characters it is truncated with trailing "..." and the rest is moved to description with a leading "..." in front.

I have a hard time coming up with a scenario where this would be a good PR title and description. The original long title is almost always preferable. If a shorter title is desired the truncated one is still non-sensical and a new one needs to be written by a human. It is still possible to submit a PR with a long title, but that requires manual copy-pasting.

Suggested alternative: don't truncate the text, just add a warning label TITLE LONGER THAN 72 CHARACTERS.

Those who want to edit can, but don't need to undo machine-edits first. Those who want to submit with a long title can, without need to undo machine edits first.

As a bonus, this could be a per-repository option:

• Soft limit to N characters (warning)
• Hard limit to N characters (cannot submit PR that is over the limit)
• No limit

[StingyJack]

Upvoted, but I don't need it to be fancy with per repo options, I just don't want someone at GitHub deciding that they know better than I do what is appropriate for my commit messages.

It's as bad as the smart links stuff in Atlasssians products. I didn't give them permission to alter my words either.

[Frederick888]

I don't think removing all restrictions entirely is a good idea.

https://git-scm.com/docs/git-commit#_discussion

Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description.

So at least there should be some kind of warning to promote good commit habits.

[StingyJack]

50 characters is not enough for a complete sentence

^ that is 51 characters long, and is the compact form of "A limit of 50 characters is simply not enough for a complete sentence describing something fairly specific and technical."

While I could condense that sentence and preserve most of the meaning, often times it cannot be done. Promoting good commit message habits should not promote poor grammar and incomplete communication.

[Frederick888]

To be clear, I'm not very against the idea of stopping truncating commit subjects; I'm against doing this without adding any warnings.

Of cos it's not true that 'someone at GitHub ... know[s] better than [you] do', and in an ideal world we don't need any restrictions or warnings on GitHub's side. But in reality there are already enough devs who manage to squeeze a small paragraph with 200 characters followed by a full Jira URL into commit subject line without caring how many characters can get truncated by GitHub. The situation can only get worse if we stop truncating without adding any warnings.

So I think the 'per-repository option' mentioned by OP is actually a must if this request gets picked up by GitHub.

[StingyJack]

In an ideal world I don't have to use GitHub (or git for that matter) everyday for work. =P

The commit message is something that probably needs to be one of the things that is reviewable as part of a PR.

[nikodemus]

Note that there isn't currently any wrapping or truncation for commi messages as such: this only happens when you make a PR consisting of a single commit - so it's really not protecting anyone from long first lines, except in a single particularly annoying situation...

…

On Wed, 13 Apr 2022, 09:24 Frederick Zhang, ***@***.***> wrote: To be clear, I'm not very against the idea of stopping truncating commit subjects; I'm against doing this without adding any warnings. Of cos it's not true that 'someone at GitHub ... know[s] better than [you] do', and in an ideal world we don't need any restrictions or warnings on GitHub's side. But in reality there are already enough devs who manage to squeeze a small paragraph with 200 characters followed by a full Jira URL into commit subject line without caring how many characters can get truncated by GitHub. The situation can only get worse if we stop truncating without adding any warnings. So I think the 'per-repository option' mentioned by OP is actually a *must* if this request gets picked up by GitHub. — Reply to this email directly, view it on GitHub <#12450 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFMVA4RLMP6RJP3662RGDVEZSAZANCNFSM5P764WXQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[SpencerKaiser]

Others here have stated things similarly, but I just want to reiterate: GitHub does not know better than I do in terms of intent. If I choose to make my title long, that's my choice... 99.999% of the time when GitHub has truncated my text in the PR title, I've gone to the description, cut that text, and re-added it to the title.

Let teams decide what works for them; don't force your opinions on us...

[goncalomarques]

@SpencerKaiser do you know if this has been implemented?

[SpencerKaiser]

It was not

[tardate]

is there any chance this will ever get addressed?

github unilaterally deciding to mess with our commit messages to generate the PR title is one of the most annoying features - it is not helping, and was a bad idea from the start.

This is not really even whether you think the 50/72 rule is a good idea or needs to be consigned to the dustbin of green-screen history.

Simply this: the PR title is being generated from an existing commit, so github should just graciously step out of the way and assume that whatever commit standards one has adopted, they have already been applied when the original commit was written.

github even admits it doesn't really care about the line length because when we go and change it back to the original, gloriously long full sentence, it doesn't complain or even give a warning.

so please... just stop it;-)

[iam3yal]

Sometimes having a long and descriptive title is the right choice and GitHub shouldn't really mess with it, I mean, git itself doesn't care about it so why should you? doing git log doesn't truncate the titles by default but more importantly, GitHub makes long titles unreadable.

[cahilfoley]

Just to add another point to this, if you're in a team that uses a commit formatting convention (such as Conventional Commits or something similar) your commit messages are made longer by the prefixes and scopes that feed into other tools. When creating a PR this doesn't serve much purpose in the title, however the additional length causes the (more important) subject of the commit message to be moved into the PR description. Most of the time I find myself removing the prefix in the autogenerated title (e.g. fix(Notifications): and moving the body of the description back to the title as it wasn't actually longer than the 72 characters without the prefix anyway.

In cases like this the 72 character limit is further condensed to impossibly short messages that would incentivize omitting any useful description from commits overall. I would love to see an option to increase this limit per repo (or the removal of the truncation entirely, but I understand the argument against that) so that I can simply remove the parts I don't want manually rather than having to also edit the description.

[tardate]

or the removal of the truncation entirely, but I understand the argument against that

PS: I don't think I've seen a cogent argument for retaining the truncation (except inertia). The fact that manually entered titles are not subject to any truncation or warning is ipso facto evidence that this feature is not the result of any clear policy or design.

[DrummerB]

This could be solved by extending the PR template system that is already available to also allow specifying a title, similar to issue templates, ideally with an optional truncation setting.

[staizen-stephen]

Literally almost every PR I create has this issue. Partly because the PR title (and the original commit) show structure around what was changed. And usually, the difference is around 10 characters but I'd much prefer that GitHub just trusts me as an admin of my repo (and probably anyone else). Reviewing PRs INCLUDES checking the name of the PR. And we can write automation around that.

GitHub is in many respects the most developer-centric platform, but this is exactly the opposite.

[oprudkyi]

20+ years ago such limit would be very reasonable , especially for CRT screens :)
today it looks like something from era of dinosaurs

[eFail]

Please fix this. So much time wasted on every PR cutting the second half of my commit message back into the title field. I don't want truncation to happen ever.