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
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
Jeff King p...@peff.net 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 ;-)
On Thu, Jun 18, 2015 at 11:50 AM, Junio C Hamano gits...@pobox.com wrote:
Patrick Palka patr...@parcs.ath.cx 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
Patrick Palka patr...@parcs.ath.cx 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
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, Jun 18, 2015 at 09:49:19PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Jeff King p...@peff.net 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
Patrick Palka patr...@parcs.ath.cx 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
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
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 we
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
On Thu, Jun 18, 2015 at 2:08 PM, Junio C Hamano gits...@pobox.com wrote:
Patrick Palka patr...@parcs.ath.cx 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
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 the
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 of
On Thu, Jun 18, 2015 at 3:08 PM, Jeff King p...@peff.net 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
On Thu, Jun 18, 2015 at 5:23 PM, Jeff King p...@peff.net 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
Jeff King p...@peff.net 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,
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
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
20 matches
Mail list logo
