FWIW, I'm leaving text in this email as my mail client found it (and not reflowing as I usually do). You can clearly see the effect of one mail client assuming that the end display is doing all of the wrapping (I'll not name names). When I first read the mail it looked fine because my mail client IGNORED the inconsistencies in line wrap modes. On Wed, 2011-12-14 at 16:04 -0500, Sidney San Martín wrote: > On Dec 12, 2011, at 10:14 PM, Michael Haggerty wrote: > > > FWIW I think automatic wrapping of commit messages is a bad idea. I > > wrap my commit messages deliberately to make them look the way I want > > them to look. The assumption of an 80-character display has historical > > reasons, but it is also a relatively comfortable line-width to read > > (even on wider displays). > > A lot of Git repos live in heterogeneous environments. I played a little with some of the popular Git interfaces I can use on my computer. The majority of them… > > - compose and show commit messages in a proportional font (where the width of and formatting in "80 characters" means nothing), In virtually all modern tools the default font is the "system default" font, which is typically variable width. In some places I've even seen variable pitch font rendering (I know there's a more technical term for it, but I'm not taking the time to look it up right now) used, which is distinct in that it makes the text easier to read when there are potentially overlapping descenders and ascenders on adjoining lines while leaving text without that feature unchanged in line spacing and kerning. Try rendering ASCII-ART with that enabled! However, it is a rare GUI tool that does not allow the user to change the font to something more appropriate (I use fixed-width fonts for most programming and scripting, but they are not any more helpful for reading log messages for instance). Text-based programming tools usually just use the console font, whatever it is--and woe be to the programmer who switches their "console" font to something variable width. (Doing so makes any application written with curses/ncurses in mind look very very odd as well.) > - don’t insert line breaks when you write a commit message (and don't provide a way to do so automatically), Most of the "tools" I have seen that ignore all user-entered line breaks are actually poorly written applications attempting to protect some sort of backing database from an injection attack. Given that, many WIKI systems typically ignore single line breaks when rendering (double line breaks are taken to be paragraph breaks in those cases I am aware of), so any argument about that quickly becomes moot as well. If somebody is writing a tool that does not allow me to force multiple line breaks when desired then so far as I am concerned their tool is broken. I don't see a point in changing GIT as a whole because somebody writes a broken GUI implementation. > - do wrap commit messages when showing them. > > Jakub, you said that education was the answer to getting some consistency in line wrapping, but I have trouble imagining the makers of new tools using fixed-width text for anything other than code. Remember, as soon as you think you've idiot-proofed something somebody builds a better idiot. That's why Jakub (and many others of us) would prefer just to tell people about the way things are intended to work and then get out of the way and let people make their own mistakes. > > And given that commit messages sometimes > > contain "flowable" paragraph text, sometimes code snippets, sometimes > > ASCII art, etc, no automatic wrapping will work correctly unless > > everybody agrees that commit messages must be written in some specific > > form of markup (or lightweight markup). And I can't imagine such a > > thing ever happening. > > The two biggest websites I know of for talking about code, GitHub and Stack Overflow, both adopted flavors of Markdown. It is basically the formatting syntax already used for commit messages in the Git project itself (this email too), so can be formatted to look good in a specific environment (i.e. proportional fonts) and looks good by itself. > > (Actually, as far as I can tell commit messages are the only place GitHub doesn’t currently render user-entered text as Markdown.) > > I think, now and in the future, consistency will be found most easily in in Markdown-like formatting and least in 80 columns of fixed-width text. Given that there is little consensus even between Markdown-like formatting methods (which have in some cases been around since the advent of movable type presses, so far as I am aware) I have to agree with Michael here. -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html