{"thread":{"id":"7632","subject":"[RFD] Strange patch formats (aka tricks with unified diffs)..","startedAt":"2007-04-12T21:58:28Z","lastAt":"2007-04-18T04:02:26Z","messageCount":16,"participants":["Linus Torvalds","Junio C Hamano","Marco Costalba","Paul Mackerras","Martin Langhoff","Matthias Lederhofer","Johannes Schindelin","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39235","messageId":"Pine.LNX.4.64.0704121436050.4061@woody.linux-foundation.org","threadId":"7632","inReplyTo":null,"subject":"[RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-12T21:58:28Z","receivedAt":"2007-04-12T21:58:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nI'm not sure how many people on this list have worked with unified diffs \nfor as long as I have, and are so used to them that they can edit them up \n(and fix up line numbers etc) in their sleep.\n\nSo I don't know if people are used to some of the really nice tricks you \ncan do with them.\n\nFor example, a lot of traditional context diff patch proponents (you're \nwrong, btw) think that unified diffs are hard to read, because you don't \nsee the \"end result\". There's a really trivial trick for this, which is to \njust do\n\n\tgrep -v '^-'\n\non the patch, and suddenly you see the patch in a totally different light: \nyou see what the end result is (in a much more readable format than a \ntraditional context diff).\n\nThe reverse operation (\"grep -v '^+'\") also obviously works, but since it \njust shows the code the way it already is, the only reason to use it tends \nto be an incorrectly reversed patch, or when you just want to see the old \ncode side-by-side with the new code (which is why some people prefer \ntraditional context diffs, but the reason I hate them is that they break \nup the old/new vertically in random places, so you can't just have two \nwindows open and compare them side by side).\n\nI'm normally actually very good at doing that \"grep\" mentally, and don't \nactually often need to do it explicitly at all, unless the patch is just \npretty messy. But sometimes the patch is just confusing enough that it \nhelps to explicitly filter it.\n\nNow, the reason I mention this is that I was just in \"gitk\", and while I \nlove the gitk graphical revision view, I just noticed (once again) why I \ntend to hate most GUI programs. I can't do the clever tricks! The gitk \ndiffs are nice and colorized, but the \"show just end result\" trick just \ndoesn't work.\n\nSo I can see two ways to fix this:\n - bug Paul about alternate diff viewing capabilities in gitk. He's cc'd \n here. A way to make the \"diff\" pane show just the new one, the old one, \n or even both side-by-side with some mousy interface?\n - add some actual switch to git diff generation to hide the negative side \n of a unified diff, and add some way to just make gitk pass that switch \n in.\n\nI dunno. I realize that it's not just gitk - gitweb, qgit etc don't allow \nthe tricks *either*, but gitk was the one I just hit this with. I ended up \njust cutting-and-pasting the SHA1 and doing the thing in a terminal with \nthe shell pipeline instead. Am wondering if maybe other people have ideas \non this.\n\nMaybe I don't need this often enough for it to matter (as mentioned, I'm \nso good at doing this in squishy-ware that I read patches _without_ the \nexplicit help most of the time) but I realized that if I do it \noccasionally, perhaps people who haven't worked with unified diffs quite \nas much as I have never even realized..\n\n\t\tLinus\n"},{"id":"39242","messageId":"7vodlti4bj.fsf@assigned-by-dhcp.cox.net","threadId":"7632","inReplyTo":"Pine.LNX.4.64.0704121436050.4061@woody.linux-foundation.org","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-12T23:02:56Z","receivedAt":"2007-04-12T23:02:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I'm normally actually very good at doing that \"grep\" mentally, and don't \n> actually often need to do it explicitly at all, unless the patch is just \n> pretty messy. But sometimes the patch is just confusing enough that it \n> helps to explicitly filter it.\n>\n> Now, the reason I mention this is that I was just in \"gitk\", and while I \n> love the gitk graphical revision view, I just noticed (once again) why I \n> tend to hate most GUI programs. I can't do the clever tricks! The gitk \n> diffs are nice and colorized, but the \"show just end result\" trick just \n> doesn't work.\n\n> So I can see two ways to fix this:\n> - bug Paul about alternate diff viewing capabilities in gitk. He's cc'd \n> here. A way to make the \"diff\" pane show just the new one, the old one, \n> or even both side-by-side with some mousy interface?\n> - add some actual switch to git diff generation to hide the negative side \n> of a unified diff, and add some way to just make gitk pass that switch \n> in.\n\nThe switch itself would literally be a one-liner (see below).\n\nHowever, I suspect what you want is _not_ \"turn the negative\nside completely off\", but \"make the negative side visually more\neasily ignorable\".\n\nHow about displaying the deleted lines with light gray on white\nbackground, or something like that?\n\n> I dunno. I realize that it's not just gitk - gitweb, qgit etc don't allow \n> the tricks *either*, but gitk was the one I just hit this with. I ended up \n> just cutting-and-pasting the SHA1 and doing the thing in a terminal with \n> the shell pipeline instead. Am wondering if maybe other people have ideas \n> on this.\n\ndiff --git a/diff.c b/diff.c\nindex fbb79d7..e61abed 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -565,6 +565,8 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)\n \t}\n \n \tif (color != DIFF_FILE_NEW) {\n+\t\tif (diff_no_deleted_lines && color == DIFF_FILE_OLD)\n+\t\t\treturn;\n \t\temit_line(diff_get_color(ecbdata->color_diff, color),\n \t\t\t reset, line, len);\n \t\treturn;\n"},{"id":"39265","messageId":"e5bfff550704122238l4a453cb7g38834c7da3432d5a@mail.gmail.com","threadId":"7632","inReplyTo":"Pine.LNX.4.64.0704121436050.4061@woody.linux-foundation.org","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-04-13T05:38:31Z","receivedAt":"2007-04-13T05:38:31Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 4/12/07, Linus Torvalds wrote:\n>\n>\n> So I can see two ways to fix this:\n> - bug Paul about alternate diff viewing capabilities in gitk. He's cc'd\n> here. A way to make the \"diff\" pane show just the new one, the old one,\n> or even both side-by-side with some mousy interface?\n> - add some actual switch to git diff generation to hide the negative side\n> of a unified diff, and add some way to just make gitk pass that switch\n> in.\n>\n> I dunno. I realize that it's not just gitk - gitweb, qgit etc don't allow\n> the tricks *either*, but gitk was the one I just hit this with.\n\nCurrently in qgit you can select a revision + a file and call an\nexternal diff viewer, as example Kompare (tweakable from\n'Edir->settings->External diff viewer' menu) to view the diff\nside-by-side, or in any other way the viewer allows, for the selected\nfile.\n\nI like also the idea to hide the negative side but I would rather\nprefer a togglable command/button instead of a command line argument\nor a setting, so to allow easy and quick hide/unhide on the same\npatch.\n\nI will work on it..... ;-)\n\nThanks for idea\nMarco\n"},{"id":"39266","messageId":"17951.6252.457936.428919@cargo.ozlabs.ibm.com","threadId":"7632","inReplyTo":"Pine.LNX.4.64.0704121436050.4061@woody.linux-foundation.org","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2007-04-13T05:43:08Z","receivedAt":"2007-04-13T05:43:08Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> - bug Paul about alternate diff viewing capabilities in gitk. He's cc'd \n> here. A way to make the \"diff\" pane show just the new one, the old one, \n> or even both side-by-side with some mousy interface?\n\nShowing just the old lines, or just the new lines, would be dead easy,\nsince the Tk text widget has an \"elide\" option on tagged ranges of\ntext that effectively removes them from the display. So I don't even\nhave to change the contents of the text widget, merely the display\noptions associated with the tags that I already have attached to the\nold and new lines (that's how they get their color).\n\nSide-by-side would be more challenging.\n\nAlternatively I could provide a field where you can put in a filter\ncommand to be put between the diff generator and the display parser.\n\nHave you seen what dirdiff can do with displaying diffs? You can\nexpose more context, move old and new lines up and down (but not in a\nmanner which changes the meaning of the diff), and split context lines\ninto old/new pairs, all with the mouse. This lets me rearrange a diff\nto make it more visually meaningful and understandable. I could\nimport that stuff into gitk, since dirdiff is also written in Tcl/Tk.\n\nPaul.\n"},{"id":"39267","messageId":"46a038f90704122307i76f96029n75425410bc40ad82@mail.gmail.com","threadId":"7632","inReplyTo":"17951.6252.457936.428919@cargo.ozlabs.ibm.com","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-13T06:07:15Z","receivedAt":"2007-04-13T06:07:15Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/13/07, Paul Mackerras wrote:\n> Side-by-side would be more challenging.\n\nIf someone gets started on side-by-side, I'd love to have\nchar-level diff colouring, like xxdiff does. Oh, and chocolate\nicecream too.\n\nIf there's enough rope to get started, I'll be happy to hack it into place.\n\ncheers,\n\n\nm\n"},{"id":"39268","messageId":"7v3b34hjdh.fsf@assigned-by-dhcp.cox.net","threadId":"7632","inReplyTo":"46a038f90704122307i76f96029n75425410bc40ad82@mail.gmail.com","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-13T06:35:22Z","receivedAt":"2007-04-13T06:35:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" writes:\n\n> On 4/13/07, Paul Mackerras wrote:\n>> Side-by-side would be more challenging.\n>\n> If someone gets started on side-by-side, I'd love to have\n> char-level diff colouring,...\n> icecream too.\n\nIs it different from the --color-words (whose implementation I\nhappen to hate)?\n"},{"id":"39269","messageId":"46a038f90704130001u4161f309k7bb98bb4801ef04a@mail.gmail.com","threadId":"7632","inReplyTo":"7v3b34hjdh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-04-13T07:01:14Z","receivedAt":"2007-04-13T07:01:14Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 4/13/07, Junio C Hamano wrote:\n> \"Martin Langhoff\" writes:\n>\n> > On 4/13/07, Paul Mackerras wrote:\n> >> Side-by-side would be more challenging.\n> >\n> > If someone gets started on side-by-side, I'd love to have\n> > char-level diff colouring,...\n> > icecream too.\n>\n> Is it different from the --color-words (whose implementation I\n> happen to hate)?\n\nDidn't know about --color-words (goes away, tests...) no, nothing like\nthat. I don't like --color-words.\n\nTo see what I mean, try\n\n git-show v1.4.4:git-cvsserver.perl > file1\n git-show v1.5.1:git-cvsserver.perl > file2\n xxdiff file1 file2\n\nJust press 'n' twice to get to the 2nd \"hunk\" and you'll see what I\nmean. Next is 'n', previous is 'p'. It's useful to visualise subtle\ndifferences, and to spot commonalities in large changes.\n\nSome aspects of xxdiff UI are horrid but this feature... is great.\nProbably tries a scan for commonalities from the start and end of the\nline. And then perhaps from the middle or from each beginning of alpha\nchar sequence.\n\ncheers,\n\n\nm\n"},{"id":"39271","messageId":"20070413081049.GA26649@moooo.ath.cx","threadId":"7632","inReplyTo":"Pine.LNX.4.64.0704121436050.4061@woody.linux-foundation.org","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-04-13T08:10:50Z","receivedAt":"2007-04-13T08:10:50Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Linus Torvalds wrote:\n> - add some actual switch to git diff generation to hide the negative side \n> of a unified diff, and add some way to just make gitk pass that switch \n> in.\n\nThis one would still allow to show the added lines still colored in\ngreen. Or do I miss a way to do this? git show --color is not very\ngrep friendly because lines begin with an escape sequence.\n"},{"id":"39286","messageId":"Pine.LNX.4.64.0704130751560.28042@woody.linux-foundation.org","threadId":"7632","inReplyTo":"20070413081049.GA26649@moooo.ath.cx","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-13T15:00:18Z","receivedAt":"2007-04-13T15:00:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 13 Apr 2007, Matthias Lederhofer wrote:\n\n> Linus Torvalds wrote:\n> > - add some actual switch to git diff generation to hide the negative side \n> > of a unified diff, and add some way to just make gitk pass that switch \n> > in.\n> \n> This one would still allow to show the added lines still colored in\n> green. Or do I miss a way to do this? git show --color is not very\n> grep friendly because lines begin with an escape sequence.\n\nHeh. I'm not much for color, so I've never done it. But if you want it, \nyou should be able to just do\n\n\tgit show --color |\n\t\tgrep -v '^[^ ]*-' |\n\t\tless -RS\n\nbecause every line of a diff (and even the explanations, thanks to the \nindent-by-four rule of git log printing) should either start with a \"+/-\" \n*or* they will have a space before they will show up, so using the \"no \nspaces before the -\" rule instead of \"beginning of line\" should work..\n\nSo the above will *literally* just remove the \"---\" line and the actual \nremoval lines of the diff, even in the presense of color coding. \n\nThe exception, of course, is:\n - maybe I didn't think it through and I missed some case, and it removes \n lines it shouldn't.\n - if you make the color coding itself have spaces or something in it \n you break my assumption (but the vt100 codes should be fine)\n\nHmm?\n\n\t\tLinus\n"},{"id":"39289","messageId":"Pine.LNX.4.64.0704130812390.28042@woody.linux-foundation.org","threadId":"7632","inReplyTo":"17951.6252.457936.428919@cargo.ozlabs.ibm.com","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-13T15:16:05Z","receivedAt":"2007-04-13T15:16:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 13 Apr 2007, Paul Mackerras wrote:\n>\n> Linus Torvalds writes:\n> \n> > - bug Paul about alternate diff viewing capabilities in gitk. He's cc'd \n> > here. A way to make the \"diff\" pane show just the new one, the old one, \n> > or even both side-by-side with some mousy interface?\n> \n> Showing just the old lines, or just the new lines, would be dead easy,\n> since the Tk text widget has an \"elide\" option on tagged ranges of\n> text that effectively removes them from the display. So I don't even\n> have to change the contents of the text widget, merely the display\n> options associated with the tags that I already have attached to the\n> old and new lines (that's how they get their color).\n\nOk, just a radio button for the patch case for \"show patch\" vs \"show \nresult\" would certainly be sufficient for what I normally do. Adding the \ncase \"show origin\" for completeness (ie filter out the new lines, rather \nthan filtering out the old lines) is probably a good idea, even if I've \nnever used it.\n\n> Side-by-side would be more challenging.\n\nNot a biggie. I've used kdiff3 etc in the past, and they do a good job of \nit and it \"looks cool\", but I've never done it on a command line which \nmeans that in practice _I_ don't use it. Maybe other people do.\n\n> Have you seen what dirdiff can do with displaying diffs? You can\n> expose more context, move old and new lines up and down (but not in a\n> manner which changes the meaning of the diff), and split context lines\n> into old/new pairs, all with the mouse.\n\nI've never used dirdiff. Sounds a bit like what kdiff3 does.\n\n\t\t\tLinus\n"},{"id":"39332","messageId":"Pine.LNX.4.64.0704141051350.18846@racer.site","threadId":"7632","inReplyTo":"7v3b34hjdh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-14T08:59:44Z","receivedAt":"2007-04-14T08:59:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 12 Apr 2007, Junio C Hamano wrote:\n\n> [...] the --color-words (whose implementation I happen to hate) [...]\n\nI know that we talked about it previously. And strictly, I think it is not \nthe implementation that you hate, but the rules that were implemented.\n\nI'll have a look at what you wrote back then, and try to come up with some \nsensible alternatives, so you don't have to hate the code so much.\n\nCiao,\nDscho\n"},{"id":"39333","messageId":"7vbqhrb7r2.fsf@assigned-by-dhcp.cox.net","threadId":"7632","inReplyTo":"Pine.LNX.4.64.0704141051350.18846@racer.site","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-14T09:55:13Z","receivedAt":"2007-04-14T09:55:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Thu, 12 Apr 2007, Junio C Hamano wrote:\n>\n>> [...] the --color-words (whose implementation I happen to hate) [...]\n>\n> I know that we talked about it previously. And strictly, I think it is not \n> the implementation that you hate, but the rules that were implemented.\n>\n> I'll have a look at what you wrote back then, and try to come up with some \n> sensible alternatives, so you don't have to hate the code so much.\n\nOne sensible behaviour would be to show exactly the same output\nlines as the regular output, but color-code only the words that\nchanged. E.g (the words are capitalized to illustrate instead\nof colored here):\n\n diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt\n index 6a5fcfd..535214c 100644\n --- a/Documentation/git-cvsserver.txt\n +++ b/Documentation/git-cvsserver.txt\n @@ -125,7 +131,7 @@ By default it uses SQLite databases in the git directory, named\n temporary files in the same directory as the database file on\n write so it might not be enough to grant the users using\n git-cvsserver write access to the database file without granting\n -them ALSO write access to the directory.\n +them write access to the directory, TOO.\n\n You can configure the database backend with the following\n configuration variables:\n"},{"id":"39335","messageId":"20070414100923.GA6546@sigill.intra.peff.net","threadId":"7632","inReplyTo":"7vbqhrb7r2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-04-14T10:09:23Z","receivedAt":"2007-04-14T10:09:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Apr 14, 2007 at 02:55:13AM -0700, Junio C Hamano wrote:\n\n> One sensible behaviour would be to show exactly the same output\n> lines as the regular output, but color-code only the words that\n> changed. E.g (the words are capitalized to illustrate instead\n> of colored here):\n\nThat works great for highlighting a small change between two very\nsimilar lines (and I think that is one use of --color-words). However,\nit's terrible for the other use of color words, which is showing changes\nwhich are not well-adapted to line oriented diffs (such as flowed text).\n\nTry this:\n\ncat >orig <rewrapped < wrote:\n> On 4/12/07, Linus Torvalds wrote:\n> >\n> >\n> > So I can see two ways to fix this:\n> > - bug Paul about alternate diff viewing capabilities in gitk. He's cc'd\n> > here. A way to make the \"diff\" pane show just the new one, the old one,\n> > or even both side-by-side with some mousy interface?\n> > - add some actual switch to git diff generation to hide the negative side\n> > of a unified diff, and add some way to just make gitk pass that switch\n> > in.\n> >\n> > I dunno. I realize that it's not just gitk - gitweb, qgit etc don't allow\n> > the tricks *either*, but gitk was the one I just hit this with.\n>\n> Currently in qgit you can select a revision + a file and call an\n> external diff viewer, as example Kompare (tweakable from\n> 'Edir->settings->External diff viewer' menu) to view the diff\n> side-by-side, or in any other way the viewer allows, for the selected\n> file.\n>\n> I like also the idea to hide the negative side but I would rather\n> prefer a togglable command/button instead of a command line argument\n> or a setting, so to allow easy and quick hide/unhide on the same\n> patch.\n>\n> I will work on it..... ;-)\n>\n\nI have pushed a patch with support for toggling view of the negative\nside of an unified diff (right most 'filter' button in patch viewer\ntab or CTRL+H shortcut).\n\nIn case someone is interested repo is, as usual,\n\n git://git.kernel.org/pub/scm/qgit/qgit.git\n\n\n Marco\n\nP.S: Another two useful shortcuts are the hide/unhide of revision\ndescription header ('h' key or from 'View' menu) and hide/unhide of\nsecondary panes ('s' key or from 'View' menu) they work in all the\ndifferent tabs.\n"},{"id":"39731","messageId":"17957.30706.398078.689096@cargo.ozlabs.ibm.com","threadId":"7632","inReplyTo":"Pine.LNX.4.64.0704130812390.28042@woody.linux-foundation.org","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2007-04-18T01:44:18Z","receivedAt":"2007-04-18T01:44:18Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> Ok, just a radio button for the patch case for \"show patch\" vs \"show \n> result\" would certainly be sufficient for what I normally do. Adding the \n> case \"show origin\" for completeness (ie filter out the new lines, rather \n> than filtering out the old lines) is probably a good idea, even if I've \n> never used it.\n\nTry this patch, let me know what you think...\n\nPaul.\n\ndiff --git a/gitk b/gitk\nindex b1c65d7..a57e84c 100755\n--- a/gitk\n+++ b/gitk\n@@ -593,6 +593,7 @@ proc makewindow {} {\n frame .bleft -width $geometry(botwidth) -height $geometry(botheight)\n }\n frame .bleft.top\n+ frame .bleft.mid\n \n button .bleft.top.search -text \"Search\" -command dosearch \\\n \t-font $uifont\n@@ -602,12 +603,20 @@ proc makewindow {} {\n lappend entries $sstring\n trace add variable searchstring write incrsearch\n pack $sstring -side left -expand 1 -fill x\n+ radiobutton .bleft.mid.diff -text \"Diff\" \\\n+\t-command changediffdisp -variable diffelide -value {0 0}\n+ radiobutton .bleft.mid.old -text \"Old version\" \\\n+\t-command changediffdisp -variable diffelide -value {0 1}\n+ radiobutton .bleft.mid.new -text \"New version\" \\\n+\t-command changediffdisp -variable diffelide -value {1 0}\n+ pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left\n set ctext .bleft.ctext\n text $ctext -background $bgcolor -foreground $fgcolor \\\n \t-state disabled -font $textfont \\\n \t-yscrollcommand scrolltext -wrap none\n scrollbar .bleft.sb -command \"$ctext yview\"\n pack .bleft.top -side top -fill x\n+ pack .bleft.mid -side top -fill x\n pack .bleft.sb -side right -fill y\n pack $ctext -side left -fill both -expand 1\n lappend bglist $ctext\n@@ -4486,6 +4495,13 @@ proc getblobdiffline {bdf ids} {\n }\n }\n \n+proc changediffdisp {} {\n+ global ctext diffelide\n+\n+ $ctext tag conf d0 -elide [lindex $diffelide 0]\n+ $ctext tag conf d1 -elide [lindex $diffelide 1]\n+}\n+\n proc prevfile {} {\n global difffilestart ctext\n set prev [lindex $difffilestart 0]\n@@ -6330,6 +6346,7 @@ set highlight_paths {}\n set searchdirn -forwards\n set boldrows {}\n set boldnamerows {}\n+set diffelide {0 0}\n \n set optim_delay 16\n \n"},{"id":"39738","messageId":"alpine.LFD.0.98.0704172102020.31155@woody.linux-foundation.org","threadId":"7632","inReplyTo":"17957.30706.398078.689096@cargo.ozlabs.ibm.com","subject":"Re: [RFD] Strange patch formats (aka tricks with unified diffs)..","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-18T04:02:26Z","receivedAt":"2007-04-18T04:02:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 18 Apr 2007, Paul Mackerras wrote:\n> \n> Try this patch, let me know what you think...\n\nVery good, looks great. \n\n\t\tLinus\n"}]}