Re: Difficulty with parsing colorized diff output

I just noticed that while `wsErrorHighlight = none` fixes the problem of extra green codes for regular diff, it fails to have any effect during interactive `git add -p`. > On 2018-12-11, at 11:41 AM, George King wrote: > > I first started playing around with terminal colors about 5

Re: Difficulty with parsing colorized diff output

I first started playing around with terminal colors about 5 years ago, and I recall learning the hard way that Apple Terminal at least behaves very strangely when you have background colors cross line boundaries: background colors disappeared when I scrolled lines back into view. I filed a bug t

Re: Difficulty with parsing colorized diff output

Peff & Stefan, thank you for the feedback. For my purposes, I am content to rely on gitconfig to reduce the colors to something that I can parse without losing information. Since my first email I have found that `wsErrorHighlight = none` gets rid of the problematic extra green highlights in the

Difficulty with parsing colorized diff output

Hello, I have a rather elaborate diff highlighter that I have implemented as a post-processor to regular git output. I am writing to discuss some difficult aspects of git diff's color output that I am observing with version 2.19.2. This is not a regression report; I am trying to implement a new

Re: Git diff --no-index --no-prefix output loses leading slash in paths

This is a feature request; sorry for the confusion. My guess is that it's a corner case that was not considered due to the default prefixing. > On Jun 18, 2018, at 10:59 AM, Duy Nguyen wrote: > > On Mon, Jun 18, 2018 at 4:36 PM George King wrote: >> >> As of 2.

Git diff --no-index --no-prefix output loses leading slash in paths

highlighter that parses and reformats paths so that code editors can autodetect them and link to the files. Would the maintainers please consider fixing the output to preserve absolute paths? Thank you, George King