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), - don’t insert line breaks when you write a commit message (and don't provide a way to do so automatically), - 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. > 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. - - - ## Gitbox 1.5.1 - Commit messages written and displayed in a proportional font - Does not insert line breaks when you commit - When displaying a commit message, turns single line breaks into spaces and keeps double line breaks, wraps as needed based on the size of the viewing area (it's somewhat intelligent about this, it does preserve some line breaks; it doesn't preserve spaces used for formatting) ## Tower 1.0.3 - Commit messages written and displayed in a proportional font - Does not insert line breaks when you commit. Collapses multiple newlines into a single newline - When displaying a commit message, wraps at 100 characters and collapses multiple newlines into a single one ## GitHub (Mac app) 1.1.1 - Commit messages written and displayed in a proportional font - Inserts line breaks after 73 characters when you commit (incl. in the middle of a long identifier) - Does not wrap lines when displaying commit messages, and doesn’t provide a way to scroll to read them ## GitHub (website) - Commit messages written and displayed in a fixed-width font - Does not insert line breaks when you commit, input wraps, visually, at 113 characters - When displaying a commit message, uses CSS to wrap the commit message to 700 pixels, 100 characters ## git (default configuration in a fresh Linux Mint live cd) - Does not insert line breaks when you commit (using the default editor (nano) and pager (less, IIRC) - Does not wrap lines when displaying commit messages. -- 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