Thread (20 messages) flat view 20 messages, 7 authors, 2016-06-15

Re: Question about commit message wrapping

From: Holger Hellmuth <hidden>
Date: 2016-06-15 22:52:37

On 12.12.2011 09:41, Frans Klaver wrote:
quoted
Emails on this list are almost exclusively sent pre-wrapped to 80
character line lengths.
The result is exactly the kind of ragged output you used in your
example. Changing this behaviour may break backwards compatibility,
but it is already broken for 'future' compatibility.
I don't really see backwards compatibility broken either. At the moment 
commit messages are usually pre-wrapped at 72 columns, which looks 
perfect only on 80 column displays, ok on wider displays and bad on 
narrow displays.

If the requirement to pre-wrap would fall and either 'git log' or 'less' 
doing the wrap, old commit messages would still look perfect on 80 
column, ok on wider and bad on narrow displays. Newer commit messages 
would look good everywhere.

The only breakage would be that new long commit messages would look bad 
on older git versions. Because of that the auto-wrap should be 
implemented first and the "requirement" for 72 columns should fall in a 
later version.
I am starting to think that we need to somehow keep the current
behavior, but override at smaller widths. Maybe even use format=flowed
in format-patch.
Could you explain what overriding at smaller widths would achieve? 
Supporting format=flowed would be nice though.
On the other hand, the fundamental use with git is to
communicate code, and I'm not sure how that [cw]ould be handled.
I prefer wrapped code to code that is cut of at a specific column. 
Wrapped code has much less possibility for misinterpretation. Python 
programmers might disagree?

I see your proposal mainly as an improvement to the display of texts, 
not code.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help