{"thread":{"id":"26705","subject":"[PATCH v2] commit, status: #comment diff output in verbose mode","startedAt":"2011-03-10T19:59:00Z","lastAt":"2011-03-17T19:41:22Z","messageCount":11,"participants":["Ian Ward Comfort","Jeff King","SZEDER Gábor","Junio C Hamano","Michael J Gruber","Piotr Krukowiecki"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"163171","messageId":"1299787140-21472-1-git-send-email-icomfort@stanford.edu","threadId":"26705","inReplyTo":null,"subject":"[PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"Ian Ward Comfort","fromEmail":"icomfort@stanford.edu","sentAt":"2011-03-10T19:59:00Z","receivedAt":"2011-03-10T19:59:00Z","isPatch":true,"sender":{"key":"icomfort@stanford.edu","avatar":"https://avatars.githubusercontent.com/u/202841?v=4"},"body":"By historical accident, diffs included in commit templates and status\noutput when the \"-v\" option is given are not prefixed with the # comment\ncharacter, as other advice and status information is. Stripping these\nlines is thus a best-effort operation, as it is not always possible to\ntell which lines were generated by \"-v\" and which were inserted by the\nuser.\n\nImprove this situation by adding the # prefix to diff output along with\nall other status output in these cases. The change is simply made thanks\nto a3c158d (Add a prefix output callback to diff output, 2010-05-26). The\nprefixed diff can be stripped (or not, as configured) by the standard\ncleanup code, so our special verbose-mode heuristic can be removed.\n\nDocumentation and a few tests which rely on the old \"-v\" format are\nupdated to match. One known breakage is fixed in t7507.\n\nSigned-off-by: Ian Ward Comfort <icomfort@stanford.edu>\n---\nResending this patch from the \"commit notes workflow\" thread ($gmane/168387)\nsince I didn't see it in \"What's cooking\". v2 changes only the placement of\nsed in t4030, to match surrounding tests a little better.\n\n(If there's no interest in this change, I'll drop it.)\n\n Documentation/git-commit.txt |    3 +--\n builtin/commit.c             |    7 -------\n t/t4030-diff-textconv.sh     |    2 +-\n t/t7502-commit.sh            |    4 ++--\n t/t7507-commit-verbose.sh    |    4 ++--\n wt-status.c                  |   12 ++++++++++++\n 6 files changed, 18 insertions(+), 14 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 8f89f6f..792f993 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -233,8 +233,7 @@ configuration variable documented in linkgit:git-config[1].\n --verbose::\n \tShow unified diff between the HEAD commit and what\n \twould be committed at the bottom of the commit message\n-\ttemplate.  Note that this diff output doesn't have its\n-\tlines prefixed with '#'.\n+\ttemplate.\n \n -q::\n --quiet::\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex 355b2cb..efecac3 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -1381,13 +1381,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \t\tdie(\"could not read commit message: %s\", strerror(saved_errno));\n \t}\n \n-\t/* Truncate the message just before the diff, if any. */\n-\tif (verbose) {\n-\t\tp = strstr(sb.buf, \"\\ndiff --git \");\n-\t\tif (p != NULL)\n-\t\t\tstrbuf_setlen(&sb, p - sb.buf + 1);\n-\t}\n-\n \tif (cleanup_mode != CLEANUP_NONE)\n \t\tstripspace(&sb, cleanup_mode == CLEANUP_ALL);\n \tif (message_is_empty(&sb) && !allow_empty_message) {\ndiff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh\nindex 88c5619..8d82faa 100755\n--- a/t/t4030-diff-textconv.sh\n+++ b/t/t4030-diff-textconv.sh\n@@ -78,7 +78,7 @@ test_expect_success 'format-patch produces binary' '\n \n test_expect_success 'status -v produces text' '\n \tgit reset --soft HEAD^ &&\n-\tgit status -v >diff &&\n+\tgit status -v | sed -e \"s/^# //\" >diff &&\n \tfind_diff <diff >actual &&\n \ttest_cmp expect.text actual &&\n \tgit reset --soft HEAD@{1}\ndiff --git a/t/t7502-commit.sh b/t/t7502-commit.sh\nindex 50da034..a916001 100755\n--- a/t/t7502-commit.sh\n+++ b/t/t7502-commit.sh\n@@ -151,8 +151,8 @@ test_expect_success 'verbose' '\n \n \techo minus >negative &&\n \tgit add negative &&\n-\tgit status -v | sed -ne \"/^diff --git /p\" >actual &&\n-\techo \"diff --git a/negative b/negative\" >expect &&\n+\tgit status -v | sed -ne \"/^# diff --git /p\" >actual &&\n+\techo \"# diff --git a/negative b/negative\" >expect &&\n \ttest_cmp expect actual\n \n '\ndiff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh\nindex da5bd3b..5b21bbb 100755\n--- a/t/t7507-commit-verbose.sh\n+++ b/t/t7507-commit-verbose.sh\n@@ -5,7 +5,7 @@ test_description='verbose commit template'\n \n cat >check-for-diff <<EOF\n #!$SHELL_PATH\n-exec grep '^diff --git' \"\\$1\"\n+exec grep '^# diff --git' \"\\$1\"\n EOF\n chmod +x check-for-diff\n test_set_editor \"$PWD/check-for-diff\"\n@@ -65,7 +65,7 @@ test_expect_success 'diff in message is retained without -v' '\n \tcheck_message diff\n '\n \n-test_expect_failure 'diff in message is retained with -v' '\n+test_expect_success 'diff in message is retained with -v' '\n \tgit commit --amend -F diff -v &&\n \tcheck_message diff\n '\ndiff --git a/wt-status.c b/wt-status.c\nindex a82b11d..fc0063e 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -32,6 +32,12 @@ static const char *color(int slot, struct wt_status *s)\n \treturn c;\n }\n \n+static struct strbuf *diff_output_prefix_callback(struct diff_options *opt, void *data)\n+{\n+\tassert(data);\n+\treturn (struct strbuf *)data;\n+}\n+\n void wt_status_prepare(struct wt_status *s)\n {\n \tunsigned char sha1[20];\n@@ -588,6 +594,7 @@ static void wt_status_print_verbose(struct wt_status *s)\n {\n \tstruct rev_info rev;\n \tstruct setup_revision_opt opt;\n+\tstruct strbuf diff_output_prefix = STRBUF_INIT;\n \n \tinit_revisions(&rev, NULL);\n \tDIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);\n@@ -596,10 +603,14 @@ static void wt_status_print_verbose(struct wt_status *s)\n \topt.def = s->is_initial ? EMPTY_TREE_SHA1_HEX : s->reference;\n \tsetup_revisions(0, NULL, &rev, &opt);\n \n+\tstrbuf_addstr(&diff_output_prefix, \"# \");\n+\n \trev.diffopt.output_format |= DIFF_FORMAT_PATCH;\n \trev.diffopt.detect_rename = 1;\n \trev.diffopt.file = s->fp;\n \trev.diffopt.close_file = 0;\n+\trev.diffopt.output_prefix = diff_output_prefix_callback;\n+\trev.diffopt.output_prefix_data = &diff_output_prefix;\n \t/*\n \t * If we're not going to stdout, then we definitely don't\n \t * want color, since we are going to the commit message\n@@ -609,6 +620,7 @@ static void wt_status_print_verbose(struct wt_status *s)\n \tif (s->fp != stdout)\n \t\tDIFF_OPT_CLR(&rev.diffopt, COLOR_DIFF);\n \trun_diff_index(&rev, 1);\n+\tstrbuf_release(&diff_output_prefix);\n }\n \n static void wt_status_print_tracking(struct wt_status *s)\n-- \n1.7.3.2\n"},{"id":"163185","messageId":"20110310225233.GH15828@sigill.intra.peff.net","threadId":"26705","inReplyTo":"1299787140-21472-1-git-send-email-icomfort@stanford.edu","subject":"Re: [PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-10T22:52:33Z","receivedAt":"2011-03-10T22:52:33Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 10, 2011 at 11:59:00AM -0800, Ian Ward Comfort wrote:\n\n> By historical accident, diffs included in commit templates and status\n> output when the \"-v\" option is given are not prefixed with the # comment\n> character, as other advice and status information is. Stripping these\n> lines is thus a best-effort operation, as it is not always possible to\n> tell which lines were generated by \"-v\" and which were inserted by the\n> user.\n> \n> Improve this situation by adding the # prefix to diff output along with\n> all other status output in these cases. The change is simply made thanks\n> to a3c158d (Add a prefix output callback to diff output, 2010-05-26). The\n> prefixed diff can be stripped (or not, as configured) by the standard\n> cleanup code, so our special verbose-mode heuristic can be removed.\n> \n> Documentation and a few tests which rely on the old \"-v\" format are\n> updated to match. One known breakage is fixed in t7507.\n\nOne reason to keep the existing behavior is that editors will tend to\nsyntax-highlight the diff portion without much extra effort (in vim, at\nleast, the syntax highlighting just includes the diff syntax\nhighlighting for that section). I have no idea if this would make things\nmuch harder for that case or not.\n\nEven if it does make things harder there, I am not sure that the\nincreased robustness isn't more important, anyway. But I thought I would\npoint it out.\n\n-Peff\n"},{"id":"163190","messageId":"20110310235703.GA15629@neumann","threadId":"26705","inReplyTo":"20110310225233.GH15828@sigill.intra.peff.net","subject":"Re: [PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2011-03-10T23:57:03Z","receivedAt":"2011-03-10T23:57:03Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Mar 10, 2011 at 05:52:33PM -0500, Jeff King wrote:\n> On Thu, Mar 10, 2011 at 11:59:00AM -0800, Ian Ward Comfort wrote:\n> \n> > By historical accident, diffs included in commit templates and status\n> > output when the \"-v\" option is given are not prefixed with the # comment\n> > character, as other advice and status information is. Stripping these\n> > lines is thus a best-effort operation, as it is not always possible to\n> > tell which lines were generated by \"-v\" and which were inserted by the\n> > user.\n> > \n> > Improve this situation by adding the # prefix to diff output along with\n> > all other status output in these cases. The change is simply made thanks\n> > to a3c158d (Add a prefix output callback to diff output, 2010-05-26). The\n> > prefixed diff can be stripped (or not, as configured) by the standard\n> > cleanup code, so our special verbose-mode heuristic can be removed.\n> > \n> > Documentation and a few tests which rely on the old \"-v\" format are\n> > updated to match. One known breakage is fixed in t7507.\n> \n> One reason to keep the existing behavior is that editors will tend to\n> syntax-highlight the diff portion without much extra effort (in vim, at\n> least, the syntax highlighting just includes the diff syntax\n> highlighting for that section). I have no idea if this would make things\n> much harder for that case or not.\n> \n> Even if it does make things harder there, I am not sure that the\n> increased robustness isn't more important, anyway. But I thought I would\n> point it out.\n\nWe had robustness issues with 'git commit -v' in the past, and Junio's\nsuggestion was to use \"# Everything under this line is deleted.\" at\nthe beginning of the commit message template, and do so after the\neditor exits.  That would work with syntax highlighting (well, at\nleast with vim), and perhaps isn't any less robust than prefixing the\ndiff output with #.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/100525/focus=100655\n\n\nBest,\nGábor\n"},{"id":"163193","messageId":"7vvczq1o4l.fsf@alter.siamese.dyndns.org","threadId":"26705","inReplyTo":"20110310225233.GH15828@sigill.intra.peff.net","subject":"Re: [PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-11T00:45:14Z","receivedAt":"2011-03-11T00:45:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> One reason to keep the existing behavior is that editors will tend to\n> syntax-highlight the diff portion without much extra effort (in vim, at\n> least, the syntax highlighting just includes the diff syntax\n> highlighting for that section).\n\nHmm, thanks for pointing it out; it indeed is a valid concern.\n\nAlthough I usually strongly resist changes in order to keep the user\nexperience stable, I didn't think about this one, as I don't let the\neditor syntax highlight anything.\n"},{"id":"163197","messageId":"20110311012318.GB15377@sigill.intra.peff.net","threadId":"26705","inReplyTo":"7vvczq1o4l.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-11T01:23:18Z","receivedAt":"2011-03-11T01:23:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 10, 2011 at 04:45:14PM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > One reason to keep the existing behavior is that editors will tend to\n> > syntax-highlight the diff portion without much extra effort (in vim, at\n> > least, the syntax highlighting just includes the diff syntax\n> > highlighting for that section).\n> \n> Hmm, thanks for pointing it out; it indeed is a valid concern.\n> \n> Although I usually strongly resist changes in order to keep the user\n> experience stable, I didn't think about this one, as I don't let the\n> editor syntax highlight anything.\n\nI like the proposal for:\n\n  # Lines below this one will be removed.\n  diff --git ...\n\nwhich seems to have the best of both worlds, robust and easy for editors\nto recognize as a diff. For that matter, we could also do \"# Lines below\nthis one...\" for _all_ of the git-status template, but I don't think\nit's necessary. Those lines are already clearly marked with a delimiter,\nand I don't think anybody is complaining about them (and the \"Lines\nbelow this one...\" line adds just one more line of cruft).\n\n-Peff\n"},{"id":"163203","messageId":"20110311053107.GB16605@sigill.intra.peff.net","threadId":"26705","inReplyTo":"20110311012318.GB15377@sigill.intra.peff.net","subject":"Re: [PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-11T05:31:07Z","receivedAt":"2011-03-11T05:31:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 10, 2011 at 08:23:18PM -0500, Jeff King wrote:\n\n> I like the proposal for:\n> \n>   # Lines below this one will be removed.\n>   diff --git ...\n> \n> which seems to have the best of both worlds, robust and easy for editors\n> to recognize as a diff. For that matter, we could also do \"# Lines below\n> this one...\" for _all_ of the git-status template, but I don't think\n> it's necessary. Those lines are already clearly marked with a delimiter,\n> and I don't think anybody is complaining about them (and the \"Lines\n> below this one...\" line adds just one more line of cruft).\n\nHmm, actually the proposal that Gábor mentioned here:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/100525/focus=100655\n\nwas to mark the whole status template as \"everything below this line is\nuninteresting\". And I was wrong that it would add one more line of\ncruft; we already have a line saying \"lines with '#' will be ignored\",\nso it would be replacing it.\n\nI do still think I prefer the \"#\" as comment lines, though. Editors\nunderstand that concept pretty well. For example, one thing that happens\nto me a lot is that I write a paragraph, then edit it, then ask the\neditor to re-wrap it. Inevitably it buts against the \"#\" lines, and\nthose get re-wrapped, too. I could fix it, of course, but I don't bother\nbecause the editor knows that the stuff on \"#\" lines should remain on\n\"#\" lines. So as it is now, the git-status output gets scrambled, but I\ndon't have to care. With a special \"# Lines below this one...\" line, I\nwill have mangled it and get extra cruft in my commit message.\n\nBut I admit that this is one pretty bizarre personal anecdote and might\nnot affect anyone else.\n\n-Peff\n"},{"id":"163212","messageId":"4D79E21A.3040007@drmicha.warpmail.net","threadId":"26705","inReplyTo":"20110311053107.GB16605@sigill.intra.peff.net","subject":"Re: [PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-11T08:49:30Z","receivedAt":"2011-03-11T08:49:30Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 11.03.2011 06:31:\n> On Thu, Mar 10, 2011 at 08:23:18PM -0500, Jeff King wrote:\n> \n>> I like the proposal for:\n>>\n>>   # Lines below this one will be removed.\n>>   diff --git ...\n>>\n>> which seems to have the best of both worlds, robust and easy for editors\n>> to recognize as a diff. For that matter, we could also do \"# Lines below\n>> this one...\" for _all_ of the git-status template, but I don't think\n>> it's necessary. Those lines are already clearly marked with a delimiter,\n>> and I don't think anybody is complaining about them (and the \"Lines\n>> below this one...\" line adds just one more line of cruft).\n> \n> Hmm, actually the proposal that Gábor mentioned here:\n> \n>   http://thread.gmane.org/gmane.comp.version-control.git/100525/focus=100655\n> \n> was to mark the whole status template as \"everything below this line is\n> uninteresting\". And I was wrong that it would add one more line of\n> cruft; we already have a line saying \"lines with '#' will be ignored\",\n> so it would be replacing it.\n> \n> I do still think I prefer the \"#\" as comment lines, though. Editors\n> understand that concept pretty well. For example, one thing that happens\n> to me a lot is that I write a paragraph, then edit it, then ask the\n> editor to re-wrap it. Inevitably it buts against the \"#\" lines, and\n> those get re-wrapped, too. I could fix it, of course, but I don't bother\n> because the editor knows that the stuff on \"#\" lines should remain on\n> \"#\" lines. So as it is now, the git-status output gets scrambled, but I\n> don't have to care. With a special \"# Lines below this one...\" line, I\n> will have mangled it and get extra cruft in my commit message.\n\nAs long as we match for the first n characters of that line with n<60 or\nso the rewrapping will do no harm (assuming you leave it to start a new\nparagraph, i.e. \"^#Lines...\" stays \"^#Lines...\").\n\n> \n> But I admit that this is one pretty bizarre personal anecdote and might\n> not affect anyone else.\n\nWhat affects me more is when when I track files in a different encoding\n(latin1, say), the diff triggers that encoding for vim and I end up with\nencoding issues for the commit message (which is supposed to be utf8)...\n\nMichael\n"},{"id":"163294","messageId":"AANLkTi=csBKvpBew9QMbD6UA774K_t6h+O4kK1-qa=FC@mail.gmail.com","threadId":"26705","inReplyTo":"20110311012318.GB15377@sigill.intra.peff.net","subject":"Re: [PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-03-13T18:34:22Z","receivedAt":"2011-03-13T18:34:22Z","isPatch":true,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Fri, Mar 11, 2011 at 2:23 AM, Jeff King <peff@peff.net> wrote:\n> On Thu, Mar 10, 2011 at 04:45:14PM -0800, Junio C Hamano wrote:\n>\n>> Jeff King <peff@peff.net> writes:\n>>\n>> > One reason to keep the existing behavior is that editors will tend to\n>> > syntax-highlight the diff portion without much extra effort (in vim, at\n>> > least, the syntax highlighting just includes the diff syntax\n>> > highlighting for that section).\n>>\n>> Hmm, thanks for pointing it out; it indeed is a valid concern.\n>>\n>> Although I usually strongly resist changes in order to keep the user\n>> experience stable, I didn't think about this one, as I don't let the\n>> editor syntax highlight anything.\n\n/me too - I find syntax highlighting a nice feature and would prefer it to\nstay as it is over using #commented out diff\n\n\n> I like the proposal for:\n>\n>  # Lines below this one will be removed.\n>  diff --git ...\n>\n> which seems to have the best of both worlds, robust and easy for editors\n> to recognize as a diff. For that matter, we could also do \"# Lines below\n> this one...\" for _all_ of the git-status template, but I don't think\n> it's necessary. Those lines are already clearly marked with a delimiter,\n> and I don't think anybody is complaining about them\n\nThe advantage of using such line is that it's more unique - IMO it's less likely\nsomeone writes a commit message with \"# Lines below ...\" etc then with\n\"diff --git\".\n\nIt also makes possible to remove this line and thus include git diff output in\ncommit message.\n\nThe downside is probably the need to support i18n for \"# Lines below ...\"\n\nLess magic formats (or formats less magic) is better IMO.\n\n-- \nPiotr Krukowiecki\n"},{"id":"163537","messageId":"20110317073719.GJ11931@sigill.intra.peff.net","threadId":"26705","inReplyTo":"4D79E21A.3040007@drmicha.warpmail.net","subject":"Re: [PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-17T07:37:19Z","receivedAt":"2011-03-17T07:37:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 11, 2011 at 09:49:30AM +0100, Michael J Gruber wrote:\n\n> > I do still think I prefer the \"#\" as comment lines, though. Editors\n> > understand that concept pretty well. For example, one thing that happens\n> > to me a lot is that I write a paragraph, then edit it, then ask the\n> > editor to re-wrap it. Inevitably it buts against the \"#\" lines, and\n> > those get re-wrapped, too. I could fix it, of course, but I don't bother\n> > because the editor knows that the stuff on \"#\" lines should remain on\n> > \"#\" lines. So as it is now, the git-status output gets scrambled, but I\n> > don't have to care. With a special \"# Lines below this one...\" line, I\n> > will have mangled it and get extra cruft in my commit message.\n> \n> As long as we match for the first n characters of that line with n<60 or\n> so the rewrapping will do no harm (assuming you leave it to start a new\n> paragraph, i.e. \"^#Lines...\" stays \"^#Lines...\").\n\nYeah, that would work in my case.\n\n> > But I admit that this is one pretty bizarre personal anecdote and might\n> > not affect anyone else.\n> \n> What affects me more is when when I track files in a different encoding\n> (latin1, say), the diff triggers that encoding for vim and I end up with\n> encoding issues for the commit message (which is supposed to be utf8)...\n\nYuck. You may be literally feeding different charsets into a single\nbuffer of the editor. The best you could do is something like:\n\n  au BufNewFile,BufRead COMMIT_EDITMSG set fenc=utf-8\n\nand then for an empty commit message, vim will read in the latin1, and\nthen convert it to utf-8 on output. You will not have munged the \"diff\"\nline, so git will still recognize it and remove everything after. But if\nyou are amending, then you will feed it a utf-8 commit message along\nwith a latin1 diff. And vim will screw that up when reading it in.\n\n-Peff\n"},{"id":"163540","messageId":"4D81BFDD.7050009@drmicha.warpmail.net","threadId":"26705","inReplyTo":"20110317073719.GJ11931@sigill.intra.peff.net","subject":"Re: [PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-17T08:01:33Z","receivedAt":"2011-03-17T08:01:33Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 17.03.2011 08:37:\n> On Fri, Mar 11, 2011 at 09:49:30AM +0100, Michael J Gruber wrote:\n> \n>>> I do still think I prefer the \"#\" as comment lines, though. Editors\n>>> understand that concept pretty well. For example, one thing that happens\n>>> to me a lot is that I write a paragraph, then edit it, then ask the\n>>> editor to re-wrap it. Inevitably it buts against the \"#\" lines, and\n>>> those get re-wrapped, too. I could fix it, of course, but I don't bother\n>>> because the editor knows that the stuff on \"#\" lines should remain on\n>>> \"#\" lines. So as it is now, the git-status output gets scrambled, but I\n>>> don't have to care. With a special \"# Lines below this one...\" line, I\n>>> will have mangled it and get extra cruft in my commit message.\n>>\n>> As long as we match for the first n characters of that line with n<60 or\n>> so the rewrapping will do no harm (assuming you leave it to start a new\n>> paragraph, i.e. \"^#Lines...\" stays \"^#Lines...\").\n> \n> Yeah, that would work in my case.\n> \n>>> But I admit that this is one pretty bizarre personal anecdote and might\n>>> not affect anyone else.\n>>\n>> What affects me more is when when I track files in a different encoding\n>> (latin1, say), the diff triggers that encoding for vim and I end up with\n>> encoding issues for the commit message (which is supposed to be utf8)...\n> \n> Yuck. You may be literally feeding different charsets into a single\n> buffer of the editor. The best you could do is something like:\n> \n>   au BufNewFile,BufRead COMMIT_EDITMSG set fenc=utf-8\n> \n> and then for an empty commit message, vim will read in the latin1, and\n> then convert it to utf-8 on output. You will not have munged the \"diff\"\n> line, so git will still recognize it and remove everything after. But if\n> you are amending, then you will feed it a utf-8 commit message along\n> with a latin1 diff. And vim will screw that up when reading it in.\n\nI resorted to using\n\ngit config diff.latin1.textconv \"iconv -f latin1\"\n\nand setting a latin1 attribute on my (php) files (which use\ninstitute-wide templates enforcing latin1).\n\nThis gives me better diffs also, of course. I just hadn't bothered so far.\n\nThough I'm wondering whether we should do something about it in general\n(we assume utf8 commit messages, don't we), at least in doc. Your\nsuggestion above does make things safer (so that you don't screw up the\ncommit message accidentally) and would make a good patch to vim's\nfiletype.vim\n\nMichael\n"},{"id":"163580","messageId":"20110317194122.GE20508@sigill.intra.peff.net","threadId":"26705","inReplyTo":"4D81BFDD.7050009@drmicha.warpmail.net","subject":"Re: [PATCH v2] commit, status: #comment diff output in verbose mode","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-17T19:41:22Z","receivedAt":"2011-03-17T19:41:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 17, 2011 at 09:01:33AM +0100, Michael J Gruber wrote:\n\n> > Yuck. You may be literally feeding different charsets into a single\n> > buffer of the editor. The best you could do is something like:\n> > \n> >   au BufNewFile,BufRead COMMIT_EDITMSG set fenc=utf-8\n>\n> [...]\n>\n> Though I'm wondering whether we should do something about it in general\n> (we assume utf8 commit messages, don't we), at least in doc. Your\n> suggestion above does make things safer (so that you don't screw up the\n> commit message accidentally) and would make a good patch to vim's\n> filetype.vim\n\nBeing perfectly content with ASCII for my native language, I am not a\ngood person to judge. But I wonder how common your situation is. That\nis, your files are all in latin1, but you continue to use utf8 for your\ncommit messages. Perhaps an easier solution would just be to tell git\nthat you want to make commit messages in latin1?\n\n-Peff\n"}]}