Hey Drew. Sorry about the lag; I really appreciate your (and the other guys on the list) taking the time to write back. You made some interesting points in your last email and I want to respond to them. - - - It may come down to personal preference and how we are each used to editing text. All the programs I use on a daily basis use soft line wrapping (not encoding any of the line breaks I see on screen into what I’m typing). Most of them use proportional type too. So, I guess I don’t *expect* to be able to manage how text wraps. Neither my email client nor the editor I use to write commit messages are set up for hard wrapping. I posed the question to the list because having to switch into “I have to hit return every so often” mode (or play with my editor) to write commit message screws with my head, and lately I just stopped doing it in my own projects. I was wondering if anyone else was thinking along the same lines and would prefer to write their commits without line breaks (except to break paragraphs, lists, etc.). On Jan 1, 2012, at 8:03 AM, Drew Northup wrote: > 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. That's interesting — it looks like my main mail client, Apple Mail, uses tricks (which I think we've discovered are mostly powered by quoted-printable encoding) to get around the old SMTP line length limits. (Is there where the differences in behavior between mail clients come from? I don't know much about the history.) As a result, I’m not really sure what you mean. What effects and inconsistencies are you seeing? My phone, my computer, and my webmail (Google) all show pretty much the same thing: the lines from your and Michael’s emails are wrapped at ~72 characters, and the lines from my email are wrapped to the width of the window. But, they all look OK. The only side effect is that on my phone, your/Michael’s text breaks about half way through every other line (since it's wrapped to a wider width than fits on the screen). I don’t think I have ever manually reflowed text like you mention. When do you do it, and why? (It may be that the thing I’m proposing wouldn’t be appropriate for git itself and other repos that use email to exchange patches. I use remotes for the repos I use on a daily basis, so I don’t have to deal with email clients like you guys do.) > 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). That’s not really the motivation behind my proposal, but I checked and actually none of the GUIs I tested before have options to change to a fixed-width font for commit messages. It’s not really the point, though. Proportional type is nice! Have you ever seen Docco? It’s a tool that takes a well-commented source file like <http://documentcloud.github.com/backbone/backbone.js> and creates a beautiful two-column view like <http://documentcloud.github.com/backbone/docs/backbone.html> with the comments on one side in a nice (for text) proportional font and the code on the other in a nice (for code) monospaced one. The text and the code both each look great. I want the guys who develop the next generation of git clients to have the same freedom to make commit messages look great. ASCII art in text has been a casualty of the rise of proportional type… but there are ways to save it (GitHub’s code blocks are an example); teaching everyone (and forcing the tools) to format text the old way is, I believe, the wrong approach. > 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.) What about manpages? They use the console font but lines get wrapped to the width of the terminal (and I want this feature of git to do that, too). They’re *not* preformatted in terms of width. >> - 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. Misunderstanding — the tools I tested don’t insert don’t insert line breaks for you to help you wrap your commit messages to a certain width. They keep user-entered line breaks (but since they use proportional type and lack column counters, there’s no way to wrap to 72 columns, even by hand, except by copying and pasting from another editor… or counting). > >> - 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. See above, this isn’t idiot-proofing. New tools use proportional fonts because they’re more readable, and soft wrapping because it makes sense in the context that they create and read commit messages. >>> 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. I think that the syntax laid out at <http://daringfireball.net/projects/markdown/syntax> is pretty consistently-used. Any differences that you think would affect this case? I think only a small subset would be relevant (paragraph breaks, ordered and unordered lists, and indented code blocks) and every implementation I’ve seen handles those the same way. I think that supporting this small subset, and only for users who turn it on, would work. It matches how many commits are already formatted, there’s nothing new to learn. P.S. Happy belated New Year!-- 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