| Issue 471: | Change rejected for whitespace issues showed up anyway | |
| 2 people starred this issue and may be notified of changes. | Back to list |
Affected Version: today's What steps will reproduce the problem? 1. Submit a change which fails the draconian new line length requirements What is the expected output? What do you see instead? Expect not to see the change in gerrit but in fact it is there. Please provide any additional information below. One change where I saw this was 42404. BTW why the new line length restrictions? Do we really still need to make people break their lines manually?
Feb 26, 2010
#1
sop@google.com
Status:
WontFix
Feb 26, 2010
I don't suppose you fancy making it possible to disable the warning (either per-user or per-server)? All the tools we use seem like they could care less about long lines and happily display them without a problem (This includes git log), and when I'm writing a commit log my first instinct on my 24" monitor isn't "oh, I need to wrap this at a quarter of the width of my monitor"
Feb 26, 2010
Sorry sop, I misunderstood what happened. I was watching over someone's shoulder as they submitted that change and their impression was that it was a hard failure. A warning seems like a reasonable behavior but the current text may imply that it's necessary to change the commit message and upload again. I don't want to try to overrule everyone on the mailing list but philosophically I think that requiring users to provide non-meaningful hard line breaks is wrong. I would rather read long commit messages in today's git log than set up my editor to generate hard breaks that make the message unsuitable for any display width other than a standard terminal.
Jul 27, 2010
I also agree with virgilk. How about making line wrapping optional?
Jul 27, 2010
I'm really against it because the only Git tool that line wraps commit messages automatically is another fringe product, EGit (the Eclipse Git plugin). Every other tool out there that matters requires hard line wrapping at commit time in order to get a readable message in those tools. Adding automatic wrapping in Gerrit's web UI only helps Gerrit web UI users, and it puts everyone else at a disadvantage. *IF* someone sends me a change containing a really well written implementation of optional line wrapping in the web UI, and it merges cleanly, I'll seriously consider including it in a future version of Gerrit. But I really don't want this, so I won't even take the time to try and correct minor issues in the change, or to cherry-pick it onto current master if it gets out of date. Usually I'm willing to help an author clean up their code, because I want the feature or bug fix they are offering. Here is a case where I really don't want it, so its got to be a really compelling change for me to bring it in.
Jul 27, 2010
Not so, GitX does line wrapping both in it's commit editor and it's log display.
Jul 27, 2010
Yeah, but git-log, gitk, etc will show up with difficult-to-read commit messages. I'd prefer to see these tools stay usable and encourage developers to line-wrap as appropriate |
|
| ► Sign in to add a comment |