Re: [PATCH 2/4] Tweak diff output further to make it a bit less distracting.

LT> There's also a real technical reason for this: since the rename format LT> would not be a valid patch for a traditional "patch" program, and if we LT> ever want to actually teach "patch" to handle it, we really need to be LT> explicit. There are tons of traditional patches around that say

LT> diff -Nur a/kernel/sched.c.old b/kernel/sched.c LT> --- a/kernel/sched.c.old LT> +++ b/kernel/sched.c LT> ...

LT> and clearly the above is _not_ a rename from "sched.c.old" to "sched.c", LT> so if we want to teach "patch" about the magic git rules, we'd have to LT> have something unambiguous that a GNU patch maintainer might be willing to LT> trigger on. The combination of the "diff -git " and "rename" markers might LT> be such a thing.

LT> So it's a combination of clarity, canonical names, and "patch" issues.

I've been thinking about doing some rename detection in diff-helper for some time. Here is what that would produce in your proposed file format (BTW, wouldn't the earlier patch ready for merge already?), if you move file frotz to file nitfol and at the same time do some edits:

    diff -git a/frotz b/frotz
    rename old frotz
    rename new nitfol
    delete file mode 100644
    --- a/frotz
    +++ /dev/null
    @@ -1,2 +0,0 @@
    -xyzzy
    -rezrov
    diff -git a/nitfol b/nitfol
    rename old frotz
    rename new nitfol
    new file mode 100644
    --- /dev/null
    +++ b/nitfol
    @@ -0,0 +1,2 @@
    +xyzzy
    +rezrov
    diff -git a/nitfol b/nitfol
    rename old frotz
    rename new nitfol
    --- a/nitfol
    +++ b/nitfol
    @@ -1,2 +1,3 @@
     xyzzy
     rezrov
    +gnusto

The basic idea is to express the pure rename with traditional two patches against /dev/null, plus optionally contents patch on top after pure rename patches.

I am still debating myself where rename lines should be, though. I cannot decide so I placed them in all three in the above example.