Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> I'm normally actually very good at doing that "grep" mentally, and don't
> actually often need to do it explicitly at all, unless the patch is just
> pretty messy. But sometimes the patch is just confusing enough that it
> helps to explicitly filter it.
>
> Now, the reason I mention this is that I was just in "gitk", and while I
> love the gitk graphical revision view, I just noticed (once again) why I
> tend to hate most GUI programs. I can't do the clever tricks! The gitk
> diffs are nice and colorized, but the "show just end result" trick just
> doesn't work.
> So I can see two ways to fix this:
> - bug Paul about alternate diff viewing capabilities in gitk. He's cc'd
> here. A way to make the "diff" pane show just the new one, the old one,
> or even both side-by-side with some mousy interface?
> - add some actual switch to git diff generation to hide the negative side
> of a unified diff, and add some way to just make gitk pass that switch
> in.
The switch itself would literally be a one-liner (see below).
However, I suspect what you want is _not_ "turn the negative
side completely off", but "make the negative side visually more
easily ignorable".
How about displaying the deleted lines with light gray on white
background, or something like that?
> I dunno. I realize that it's not just gitk - gitweb, qgit etc don't allow
> the tricks *either*, but gitk was the one I just hit this with. I ended up
> just cutting-and-pasting the SHA1 and doing the thing in a terminal with
> the shell pipeline instead. Am wondering if maybe other people have ideas
> on this.
diff --git a/diff.c b/diff.c
index fbb79d7..e61abed 100644
--- a/diff.c
+++ b/diff.c
@@ -565,6 +565,8 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
}
if (color != DIFF_FILE_NEW) {
+ if (diff_no_deleted_lines && color == DIFF_FILE_OLD)
+ return;
emit_line(diff_get_color(ecbdata->color_diff, color),
reset, line, len);
return;
-
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