My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 1084: wrap long first lines of commit messages in the ui
2 people starred this issue and may be notified of changes. Back to list
Status:  WontFix
Owner:  ----
Closed:  Aug 2011


Sign in to add a comment
 
Reported by andyster, Aug 9, 2011
Affected Version: 2.2.1-1-g1f83214

What steps will reproduce the problem?
1. make a commit message with an unusually long first line
2. view it in the code review
3.

Example:
https://review.openstack.org/#change,190

What is the expected output? What do you see instead?

I'd expect to see the line wrapped to fit within a reasonable amount of space.

Please provide any additional information below.

Aug 10, 2011
Project Member #1 bklarson@gmail.com
It is a pretty standard git practice to not line wrap any of the commit message, including the first line.  git log, gitk, gitweb, etc don't do this.  Instead, you should have users follow a good commit message format guideline.. a short 1-line summary, followed by a blank line and a longer explanation of the commit.

There is a good guide for this at http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html.
Status: WontFix
Aug 10, 2011
#2 monty.ta...@gmail.com
Well - I can't say I totally agree with not wrapping in a web ui just because less happens to not wrap, nor do I think any UI style choices should be taken from gitweb. It seems like adding something to the css for that div would sort it out and make it look a little less borked.

However - not to just complain without writing code:

https://github.com/emonty/gerrit/tree/topic/block-long-messages

I added an optional patch submission blocker which will reject patches whose first commit line is too long. I also adjusted the subject message warning from 65 to 50 for consistency sake - since that is the default recommended length, both in the link above and in the standard vim git commit highlighting.

I'll submit this for real as soon as I've gotten corporate approval to sign the CLA.
Aug 10, 2011
Project Member #3 bklarson@gmail.com
I agree that the best solution is rejecting these changes and asking users to re-submit.  Thanks, and looking forward to your contribution!
Aug 10, 2011
#4 andyster
While I agree that git best practices are to have a shorter first line, by not handling long lines properly you are allowing your UI to be broken.

Principles are great, as is educating people, but be open in what you accept and strict in what you give out, not the other way around.
Sign in to add a comment

Powered by Google Project Hosting