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

From: Jeff King <peff@peff.net>
Date: Aug 18, 2016, 15:15 UTC
Message-ID: <20160818151544.7rhfe7cetl3hp3b5@sigill.intra.peff.net>
In-Reply-To: <20160818150522.56gdx2mhgo7qwvru@sigill.intra.peff.net>

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

Show 22 quoted lines

> 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.

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