From: Jakub Narebski <jnareb@gmail.com>
To: "Sidney San Martín" <s@sidneysm.com>
Cc: git@vger.kernel.org
Subject: Re: Question about commit message wrapping
Date: Sat, 10 Dec 2011 20:30:14 +0100 [thread overview]
Message-ID: <201112102030.15504.jnareb@gmail.com> (raw)
In-Reply-To: <E085218D-9287-4F82-B34C-8379742F818A@sidneysm.com>
On Fri, 9 Dec 2011, Sidney San Martín wrote:
> On Dec 9, 2011, at 8:41 AM, Jakub Narebski wrote:
>> Sidney San Martín <s@sidneysm.com> writes:
>>
>>> *Nothing else* in my everyday life works this way anymore. Line
>>> wrapping gets done on the display end in my email client, my web
>>> browser, my ebook reader entirely automatically, and it adapts to
>>> the size of the window.
>>
>> The problem with automatic wrapping on the display is that there could
>> be parts of commit message that *shouldn't* be wrapped, like code
>> sample, or URL... and in plain text you don't have a way to separate
>> flowed from non-flowed part.
Additional and the more serious problem with wrapping on output is
related to backward compatibility. If you have commit message that is
wrapped e.g. to 80 characters, and you wrap on output to 72 characters,
you would get ugly and nigh unreadable ragged output:
original:
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
occaecat cupidatat non proident, sunt in culpa qui officia deserunt
mollit anim id est laborum.
wrapped to 70th column:
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim
veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip
ex ea
commodo consequat. Duis aute irure dolor in reprehenderit in
voluptate
velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint
occaecat cupidatat non proident, sunt in culpa qui officia deserunt
mollit anim id est laborum.
You can re-wrap, but this is more code, and additional problems, like
with ASCII-art like this or pseudo-Markdown headers like this
^^^^^^^^^
Header
======
> I usually lead code, URLs, and other preformatted lines like this with
> a few spaces. Markdown uses the same convention, and it looks like
> commits in this repo do too.
>
> The patch in my last email prints lines which begin with whitespace
> verbatim. How does that work?
What about lists done using hanging indent, e.g.:
* Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
or
- Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
or
1. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
>> Also with long non-breakable identifiers you sometimes need to wrap by
>> hand (or use linebreaking algorithm from TeX) or go bit over the limit
>> to make it look nice.
>
> Could you elaborate on this? The patch uses strbuf_add_wrapped_text,
> which was already in Git. If an identifier is longer than the wrap
> width, it leaves it alone.
The line breaking algorithm of TeX typesetting engine takes into account
look of whole paragraph (well, mathematical representation of "good look")
before breaking lines and hyphenating words.
What I meant here that if you have long identifier, naive line-breaking
(word-wrapping) algorithm could leave the paragraph unbalanced, with one
or more lines much shorter than the rest, while allowing one line to be
overly long over 1 character leads to nicely wrapped result.
BTW. In Polish (and Czech) typography there is rule that you don't leave
single-letter prepositions like 'i' ('and' in English) hanging at the end
of the line... automatic wrapper cannot ensure that.
>> BTW. proper editor used to create commit message can wrap it for you
>> ;-).
>
> Only if everybody else in the world does it too!
Educate.
> And only if I never care about seeing my commits at any width besides
> 80 columns.
Overly long lines are hard to read, and sometimes fit-to-width would give
us too long lines to read comfortably.
Anyway I am not against adding support for wrapping commit message and
tag payload, but IMHO it must be *optional*: --no-wrap, --wrap=auto
(or just --wrap), --wrap=80, and log.wrap or core.wrap.
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2011-12-10 19:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-09 1:59 Question about commit message wrapping Sidney San Martín
2011-12-09 7:05 ` Frans Klaver
2011-12-09 7:51 ` Frans Klaver
2011-12-09 14:10 ` Sidney San Martín
2011-12-09 16:49 ` Frans Klaver
2011-12-09 17:49 ` Sidney San Martín
2011-12-10 9:10 ` Andreas Schwab
2011-12-09 13:41 ` Jakub Narebski
2011-12-09 17:50 ` Sidney San Martín
2011-12-10 19:30 ` Jakub Narebski [this message]
2011-12-11 22:00 ` Andrew Ardill
2011-12-12 8:41 ` Frans Klaver
2011-12-12 16:37 ` Holger Hellmuth
2011-12-12 22:16 ` Frans Klaver
2011-12-13 3:14 ` Michael Haggerty
2011-12-13 6:16 ` Frans Klaver
2011-12-13 13:14 ` Holger Hellmuth
2011-12-14 21:04 ` Sidney San Martín
2012-01-01 16:03 ` Drew Northup
2012-01-26 1:50 ` Sidney San Martín
2011-12-14 21:07 ` Sidney San Martín
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201112102030.15504.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=s@sidneysm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).