git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[RFD] Strange patch formats (aka tricks with unified diffs)..

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Apr 12, 2007, 21:58 UTC
Message-ID
<Pine.LNX.4.64.0704121436050.4061@woody.linux-foundation.org>

I'm not sure how many people on this list have worked with unified diffs for as long as I have, and are so used to them that they can edit them up (and fix up line numbers etc) in their sleep.

So I don't know if people are used to some of the really nice tricks you can do with them.

For example, a lot of traditional context diff patch proponents (you're wrong, btw) think that unified diffs are hard to read, because you don't see the "end result". There's a really trivial trick for this, which is to just do

	grep -v '^-'

on the patch, and suddenly you see the patch in a totally different light: you see what the end result is (in a much more readable format than a traditional context diff).

The reverse operation ("grep -v '^+'") also obviously works, but since it just shows the code the way it already is, the only reason to use it tends to be an incorrectly reversed patch, or when you just want to see the old code side-by-side with the new code (which is why some people prefer traditional context diffs, but the reason I hate them is that they break up the old/new vertically in random places, so you can't just have two windows open and compare them side by side).

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.

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.

Maybe I don't need this often enough for it to matter (as mentioned, I'm so good at doing this in squishy-ware that I read patches _without_ the explicit help most of the time) but I realized that if I do it occasionally, perhaps people who haven't worked with unified diffs quite as much as I have never even realized..

		Linus
Next: Junio C Hamano
Message 1 of 16 in “[RFD] Strange patch formats (aka tricks with unified diffs)..”
  1. Linus TorvaldsApr 12, 2007
  2. Junio C HamanoApr 12, 2007
  3. Marco CostalbaApr 13, 2007
  4. Marco CostalbaApr 17, 2007
  5. Paul MackerrasApr 13, 2007
  6. Martin LanghoffApr 13, 2007
  7. Junio C HamanoApr 13, 2007
  8. Martin LanghoffApr 13, 2007
  9. Johannes SchindelinApr 14, 2007
  10. Junio C HamanoApr 14, 2007
  11. Jeff KingApr 14, 2007
  12. Linus TorvaldsApr 13, 2007
  13. Paul MackerrasApr 18, 2007
  14. Linus TorvaldsApr 18, 2007
  15. Matthias LederhoferApr 13, 2007
  16. Linus TorvaldsApr 13, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.