git format-patch --break-rewrites broken in 2.9.3

This command used to create a diff which can be consumed by patch. But
at least with 2.9.3 it just gives a rename output:

 git format-patch \
        --no-signature \
        --stdout \
        --break-rewrites \
        --keep-subject \
 95fa0405c5991726e06c08ffcd8ff872f7fb4f2d^..95fa0405c5991726e06c08ffcd8ff872f7fb4f2d


What must be done now to get a usable patch?

Olaf

Hi Olaf,

On Thu, 18 Aug 2016, Olaf Hering wrote:

This command used to create a diff which can be consumed by patch. But
at least with 2.9.3 it just gives a rename output:

 git format-patch \
        --no-signature \
        --stdout \
        --break-rewrites \
        --keep-subject \
 95fa0405c5991726e06c08ffcd8ff872f7fb4f2d^..95fa0405c5991726e06c08ffcd8ff872f7fb4f2d


What must be done now to get a usable patch?

Maybe --no-renames? BTW this behavior was not introduced in 2.9.3, but in
2.9.0:

https://github.com/git/git/blob/v2.9.0/Documentation/RelNotes/2.9.0.txt#L7-L9

Ciao,
Johannes

On Thu, Aug 18, 2016 at 04:44:21PM +0200, Olaf Hering wrote:

This command used to create a diff which can be consumed by patch. But
at least with 2.9.3 it just gives a rename output:

 git format-patch \
        --no-signature \
        --stdout \
        --break-rewrites \
        --keep-subject \
 95fa0405c5991726e06c08ffcd8ff872f7fb4f2d^..95fa0405c5991726e06c08ffcd8ff872f7fb4f2d


What must be done now to get a usable patch?

Probably --no-renames.

Renames were enabled by default by 5404c11 (diff: activate diff.renames
by default, 2016-02-25), which is in v2.9.0.

I wonder if we should consider undoing that for format-patch, whose
output may be consumed by non-git endpoints.

-Peff

On Thu, Aug 18, 2016 at 11:05:22AM -0400, Jeff King wrote:

On Thu, Aug 18, 2016 at 04:44:21PM +0200, Olaf Hering wrote:

quoted

This command used to create a diff which can be consumed by patch. But
at least with 2.9.3 it just gives a rename output:

 git format-patch \
        --no-signature \
        --stdout \
        --break-rewrites \
        --keep-subject \
 95fa0405c5991726e06c08ffcd8ff872f7fb4f2d^..95fa0405c5991726e06c08ffcd8ff872f7fb4f2d


What must be done now to get a usable patch?

Probably --no-renames.

Renames were enabled by default by 5404c11 (diff: activate diff.renames
by default, 2016-02-25), which is in v2.9.0.

I wonder if we should consider undoing that for format-patch, whose
output may be consumed by non-git endpoints.

By the way, this probably has nothing to do with --break-rewrites in
particular. It would come up for any case where git finds a rename. In
the absence of --break-rewrites, that requires a path being deleted and
one being added. But in this particular case, --break-rewrites turns a
large change into a delete/add pair, which lets git find the rename.

So it's a necessary option to show the problem in _this_ instance, but
there are other cases that would not need it.

-Peff

On Thu, Aug 18, 2016 at 04:44:21PM +0200, Olaf Hering wrote:

This command used to create a diff which can be consumed by patch. But
at least with 2.9.3 it just gives a rename output:

 git format-patch \
        --no-signature \
        --stdout \
        --break-rewrites \
        --keep-subject \

95fa0405c5991726e06c08ffcd8ff872f7fb4f2d^..95fa0405c5991726e06c08ffcd8ff872f7fb4f2d


What must be done now to get a usable patch?

As an aside, the range can be shortened to

95fa0405c5991726e06c08ffcd8ff872f7fb4f2d^!

It's something I picked up when doing the doc update on 'specifying 
revisions'.

--

Philip