Jeff King writes:
> I do strip it off, so it is OK for it to be different in both the
> pre-image and post-image. But what I can't tolerate is the
> intermingling with actual data:
>
> +\t\t\x1b[32m;foo
> +\t\x1b[32m;bar
I think that depends on the definition of "strip it off" ;-) What I
me
On Fri, Jun 19, 2015 at 03:34:55AM -0400, Jeff King wrote:
> And here's some more bad news. If you look at the diff for this
> patch itself, it's terribly unreadable (the regular diff already is
> pretty bad, but the highlights make it much worse). There are big chunks
> where we take away 5 or 10
On Fri, Jun 19, 2015 at 01:32:23AM -0400, Jeff King wrote:
> The least-work thing may actually be teaching the separate
> diff-highlight script to strip out the colorizing and re-add it by
> offset.
OK, here is that patch. It seems to work OK, and should preserve
existing colors produced by git a
On Thu, Jun 18, 2015 at 09:49:19PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... I think you could also argue that
> > because of whitespace-highlighting, colorized diffs are fundamentally
> > going to have colors intermingled with the content and should not be
> > parsed this way.
Jeff King writes:
> ... I think you could also argue that
> because of whitespace-highlighting, colorized diffs are fundamentally
> going to have colors intermingled with the content and should not be
> parsed this way.
Painting of whitespace breakages is asymmetric [*1*]. If you change
somethi
On Thu, Jun 18, 2015 at 05:23:56PM -0400, Jeff King wrote:
> +# Return the individual diff-able items of the hunk, but with any
> +# diff or color prefix/suffix for each line split out (we assume that the
> +# prefix/suffix for each line will be the same).
> +sub split_hunk {
> + my ($prefix,
On Thu, 18 Jun 2015, Jeff King wrote:
On Thu, Jun 18, 2015 at 04:14:19PM -0400, Patrick Palka wrote:
in a test script becomes more clear. But some of the output is not so
great. For instance, the very commit under discussion has a
confusing and useless highlight. Or take a documentation patch
On Thu, Jun 18, 2015 at 5:23 PM, Jeff King wrote:
> On Thu, Jun 18, 2015 at 04:45:05PM -0400, Jeff King wrote:
>
>> Still, I think this is probably a minority case, and it may be
>> outweighed by the improvements. The "real" solution is to consider the
>> hunk as a whole and do an LCS diff on it,
Jeff King writes:
> On Thu, Jun 18, 2015 at 04:45:05PM -0400, Jeff King wrote:
>
>> Still, I think this is probably a minority case, and it may be
>> outweighed by the improvements. The "real" solution is to consider the
>> hunk as a whole and do an LCS diff on it, which would show that yes,
>> i
On Thu, Jun 18, 2015 at 04:45:05PM -0400, Jeff King wrote:
> Still, I think this is probably a minority case, and it may be
> outweighed by the improvements. The "real" solution is to consider the
> hunk as a whole and do an LCS diff on it, which would show that yes,
> it's worth highlighting both
On Thu, Jun 18, 2015 at 04:14:19PM -0400, Patrick Palka wrote:
> >in a test script becomes more clear. But some of the output is not so
> >great. For instance, the very commit under discussion has a
> >confusing and useless highlight. Or take a documentation patch like
> >5c31acfb, where I find th
On Thu, Jun 18, 2015 at 3:08 PM, Jeff King wrote:
> On Thu, Jun 18, 2015 at 12:28:58PM -0400, Patrick Palka wrote:
>
>> By the way, what would it take to get something like this script into
>> git proper? It is IMHO immensely useful even in its current form, yet
>> because it's not baked into the
On Thu, Jun 18, 2015 at 2:08 PM, Junio C Hamano wrote:
> Patrick Palka writes:
>
>>> I have this nagging feeling that it is just as likely that two
>>> uneven hunks align at the top as they align at the bottom, so while
>>> this might not hurt it may not be the right approach for a better
>>> sol
On Thu, 18 Jun 2015, Jeff King wrote:
On Thu, Jun 18, 2015 at 11:08:16AM -0700, Junio C Hamano wrote:
So as I said, I do not think it would hurt to have this as an
incremental improvement (albeit going in a possibly wrong
direction).
Of course, it is a separate question if this change makes t
On Thu, Jun 18, 2015 at 12:28:58PM -0400, Patrick Palka wrote:
> By the way, what would it take to get something like this script into
> git proper? It is IMHO immensely useful even in its current form, yet
> because it's not baked into the application hardly anybody knows about
> it.
I think if
On Thu, Jun 18, 2015 at 11:08:16AM -0700, Junio C Hamano wrote:
> So as I said, I do not think it would hurt to have this as an
> incremental improvement (albeit going in a possibly wrong
> direction).
>
> Of course, it is a separate question if this change makes the output
> worse, by comparing
Patrick Palka writes:
>> I have this nagging feeling that it is just as likely that two
>> uneven hunks align at the top as they align at the bottom, so while
>> this might not hurt it may not be the right approach for a better
>> solution, in the sense that when somebody really wants to do a
>>
On Thu, Jun 18, 2015 at 11:50 AM, Junio C Hamano wrote:
> Patrick Palka writes:
>
>> Currently the diff-highlight script does not try to highlight hunks that
>> have different numbers of removed/added lines. But we can be a little
>> smarter than that, without introducing much magic and complexi
Patrick Palka writes:
> Currently the diff-highlight script does not try to highlight hunks that
> have different numbers of removed/added lines. But we can be a little
> smarter than that, without introducing much magic and complexity.
>
> In the case of unevenly-sized hunks, we could still hig
Currently the diff-highlight script does not try to highlight hunks that
have different numbers of removed/added lines. But we can be a little
smarter than that, without introducing much magic and complexity.
In the case of unevenly-sized hunks, we could still highlight the first
few (lexicograph
20 matches
Mail list logo
