On Oct 28, 2010, at 4:41 PM, Junio C Hamano wrote:
>>> Kevin Ballard <kevin@xxxxxx> writes:
>>>
>>> [jc: why do you send messages with toooooooooooo loooooong lines sometimes
>>> and normal line lengths some other times...?]
>>
>> I use a GUI mail client to write email. Anything I copy&paste is hard-wrapped,
>> anything I write directly tends to not include hard linebreaks at all. Would it
>> be better if I hard-wrapped my lines?
>
> It is not better vs worse but is acceptable vs unacceptable, as hard
> wrapped messages have been the norm around here from day one. As far as I
> remember you only recently started sending messages with long lines, so I
> suspected perhaps you changed your environment and are doing so without
> realizing the pain you are causing to others.
I apologize, I did not realize it caused a problem to others. I'm not used
to interacting with people using terminal mail clients (e.g. mutt). I didn't
give it much thought, but I just assumed the ML was hard-wrapping everybody's
messages (of course this is obviously wrong, as evidenced by my own messages).
I will bear this in mind for future emails.
>>> The best would probably be to special case SP (which is normally not to be
>>> quoted) _only_ in the context of "something" -> "something".
>>
>> That's what I was thinking. I'll look into doing just that.
>
> Yeah, if we wanted to be perfect, it would be better to do so without
> causing unnecessary pain.
Turns out it's fairly simple to do.
BTW, I'm trying an experiment here to see if I can just paste the patch into
Mail.app without it being mangled. I sent it to myself first, and Mail.app
is applying quoted-printable encoding to the patch, but it appears git-am
can still understand it. Please let me know if this isn't acceptable and I
will send it separately.
---8<---
Subject: status: Quote renamed/copied paths with spaces in short format
According to the documentation for git-status, in short output mode,
paths with spaces or unprintable characters are quoted. However
28fba29 (Do not quote SP., 2005-10-17) removed the behavior that quotes
paths that have spaces but not unprintable characters. Unfortunately this
makes the output of `git status --porcelain` non-parseable in certain
(rather unusual) edge cases. In the interest of removing ambiguity when
parsing the output of `git status --porcelain`, restore the behavior of
quoting paths with spaces but only for renamed/copied paths.
Signed-off-by: Kevin Ballard <kevin@xxxxxx>
---
wt-status.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index fc2438f..9624865 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -744,10 +744,20 @@ static void wt_shortstatus_status(int null_termination, struct string_list_item
const char *one;
if (d->head_path) {
one = quote_path(d->head_path, -1, &onebuf, s->prefix);
+ if (*one != '"' && strchr(one, ' ') != NULL) {
+ putchar('"');
+ strbuf_addch(&onebuf, '"');
+ one = onebuf.buf;
+ }
printf("%s -> ", one);
strbuf_release(&onebuf);
}
one = quote_path(it->string, -1, &onebuf, s->prefix);
+ if (*one != '"' && strchr(one, ' ') != NULL) {
+ putchar('"');
+ strbuf_addch(&onebuf, '"');
+ one = onebuf.buf;
+ }
printf("%s\n", one);
strbuf_release(&onebuf);
}
--
1.7.3.2.195.ge42d1.dirty
--
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