On Sun, Oct 22, 2017 at 08:27:20AM -0400, Jason Pyeron wrote:
> > ESC (for color)
> > + if ($line =~ s/[\000-\011\013-\032\034-\037]/?/g) {
>
> What about CR [0x0D] ?
I assumed that CR was one of the things we'd want to avoid (and it was
in fact what I used to test this).
> -Original Message-
> From: Jeff King
> Sent: Monday, October 16, 2017 6:13 PM
> To: Joris Valette
> Cc: Andreas Schwab; Jason Pyeron; git@vger.kernel.org
> Subject: Re: Consider escaping special characters like 'less' does
>
>
> I.e., something like this wo
On Tue, Oct 17, 2017 at 10:13:34AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Alternatively, I suppose we could just always escape in
> > add--interactive. I'm trying to think of a case where somebody would
> > really want their diffFilter to see the raw bytes (or
Jeff King writes:
> Alternatively, I suppose we could just always escape in
> add--interactive. I'm trying to think of a case where somebody would
> really want their diffFilter to see the raw bytes (or vice versa, to
> show raw bytes produced by their filter), but I'm having
On Tue, Oct 17, 2017 at 12:47:01AM +0200, Andreas Schwab wrote:
> On Okt 16 2017, Jeff King wrote:
>
> > I can't help but feel this is the tip of a larger iceberg, though. E.g.,
> > what about characters outside of the terminal's correct encoding? Or
> > broken UTF-8 characters?
On Okt 16 2017, Jeff King wrote:
> I can't help but feel this is the tip of a larger iceberg, though. E.g.,
> what about characters outside of the terminal's correct encoding? Or
> broken UTF-8 characters?
Or correctly encoded UTF-8 characters that look confusing? Or blobs
with
On Sun, Oct 15, 2017 at 11:37:04PM +0200, Joris Valette wrote:
> 2017-10-15 22:06 GMT+02:00 Jeff King :
> > Git's diff generation will never do such escaping by default, because it
> > means creating a patch that cannot be applied to get back the original
> > content.
>
> Indeed
2017-10-15 22:06 GMT+02:00 Jeff King :
> Git's diff generation will never do such escaping by default, because it
> means creating a patch that cannot be applied to get back the original
> content.
Indeed this would be a problem. That's where my knowledge of git's
source code ends,
On Sun, Oct 15, 2017 at 06:39:45PM +0200, Joris Valette wrote:
> > It's your MUA's fault that you get a ?, the mail didn't contain any.
>
> Actually, the original mail contained the special BOM sequence but
> it's generally invisible. His MUA shows it with a '?', mine doesn't
> show anything,
; To: git@vger.kernel.org
>>> Subject: Consider escaping special characters like 'less' does
>>>
>>> The pager 'less' escapes some characters when calling 'git diff'. This
>>> is what I might get:
>>>
>>> $ git diff --cached
>>> diff --git a
On Okt 15 2017, "Jason Pyeron" <jpye...@pdinc.us> wrote:
>> -Original Message-
>> From: Joris Valette
>> Sent: Sunday, October 15, 2017 9:34 AM
>> To: git@vger.kernel.org
>> Subject: Consider escaping special characters like 'less' does
>&g
> -Original Message-
> From: Joris Valette
> Sent: Sunday, October 15, 2017 9:34 AM
> To: git@vger.kernel.org
> Subject: Consider escaping special characters like 'less' does
>
> The pager 'less' escapes some characters when calling 'git diff'. This
> is what I mi
The pager 'less' escapes some characters when calling 'git diff'. This
is what I might get:
$ git diff --cached
diff --git a/some_file b/some_file
new file mode 100644
index 000..357323f
--- /dev/null
+++ b/some_file
@@ -0,0 +1 @@
+Hello
\ No newline at end of file
This example is a
13 matches
Mail list logo