On Fri, Mar 11, 2011 at 09:49:30AM +0100, Michael J Gruber wrote: > > I do still think I prefer the "#" as comment lines, though. Editors > > understand that concept pretty well. For example, one thing that happens > > to me a lot is that I write a paragraph, then edit it, then ask the > > editor to re-wrap it. Inevitably it buts against the "#" lines, and > > those get re-wrapped, too. I could fix it, of course, but I don't bother > > because the editor knows that the stuff on "#" lines should remain on > > "#" lines. So as it is now, the git-status output gets scrambled, but I > > don't have to care. With a special "# Lines below this one..." line, I > > will have mangled it and get extra cruft in my commit message. > > As long as we match for the first n characters of that line with n<60 or > so the rewrapping will do no harm (assuming you leave it to start a new > paragraph, i.e. "^#Lines..." stays "^#Lines..."). Yeah, that would work in my case. > > But I admit that this is one pretty bizarre personal anecdote and might > > not affect anyone else. > > What affects me more is when when I track files in a different encoding > (latin1, say), the diff triggers that encoding for vim and I end up with > encoding issues for the commit message (which is supposed to be utf8)... Yuck. You may be literally feeding different charsets into a single buffer of the editor. The best you could do is something like: au BufNewFile,BufRead COMMIT_EDITMSG set fenc=utf-8 and then for an empty commit message, vim will read in the latin1, and then convert it to utf-8 on output. You will not have munged the "diff" line, so git will still recognize it and remove everything after. But if you are amending, then you will feed it a utf-8 commit message along with a latin1 diff. And vim will screw that up when reading it in. -Peff -- 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