threads / discuss / 43879
Subject: git format-patch --break-rewrites broken in 2.9.3
Olaf HeringThis 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^..95fa0405c5991726e06c08ffcd8ff872f7fb4f2dWhat must be done now to get a usable patch?
Olaf
Johannes SchindelinRe: git format-patch --break-rewrites broken in 2.9.3
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
Junio C HamanoRe: git format-patch --break-rewrites broken in 2.9.3
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Olaf, > >> --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
I think that is one half of the story.
The other half is a long/well known bug that lets "diff -B -M" to produce incorrect/broken patch that cannot be applied. It was documented in the thread that begins at:
public-inbox.org/git/xmqqfvapuhkk.fsf@gitster.dls.corp.google.com
but still hasn't been solved.
Junio C HamanoRe: git format-patch --break-rewrites broken in 2.9.3
Junio C Hamano <gitster@pobox.com> writes:
> I think that is one half of the story. > > The other half is a long/well known bug that lets "diff -B -M" to > produce incorrect/broken patch that cannot be applied. It was > documented in the thread that begins at: > > public-inbox.org/git/xmqqfvapuhkk.fsf@gitster.dls.corp.google.com > > but still hasn't been solved.
The problem report actually starts here:
public-inbox.org/git/xmqqegqaahnh.fsf@gitster.dls.corp.google.com/
Jeff KingRe: git format-patch --break-rewrites broken in 2.9.3
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
Jeff KingRe: git format-patch --break-rewrites broken in 2.9.3
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: > > > 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
Philip OakleyRe: git format-patch --break-rewrites broken in 2.9.3
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
Andreas SchwabRe: git format-patch --break-rewrites broken in 2.9.3
On Aug 19 2016, "Philip Oakley" <philipoakley@iee.org> wrote:
> 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^!
In the context of format-patch you can also use -1 to select the topmost commit from the list.
Andreas.
-- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Jeff KingRe: git format-patch --break-rewrites broken in 2.9.3
On Thu, Aug 18, 2016 at 05:16:55PM +0200, Matthieu Moy wrote:
> Jeff King <peff@peff.net> writes: > > > 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. > > I would say no (or more precisely: we should consider, but we should > reject the idea ;-) ), since patches with renames are useful and can be used > even outside Git's scope. GNU patch, which is probably the most widely > used implementation of patch supports git-style renames since 2.7, > released in September 2012.
Ah, OK; I didn't realize GNU patch had picked up rename support. I agree that makes it less-bad for format-patch to start using them by default. Olaf, what version of patch are you using?
-Peff
Olaf HeringRe: git format-patch --break-rewrites broken in 2.9.3
On Thu, Aug 18, Jeff King wrote:
> Olaf, what version of patch are you using?
Mostly 2.7.x, but also add 2.5.x to the mix. So far I did not try what the tools dealing with the resulting patch file would actually do with such a stripped down variant.
Olaf
Matthieu MoyRe: git format-patch --break-rewrites broken in 2.9.3
Olaf Hering <olaf@aepfle.de> writes:
> On Thu, Aug 18, Jeff King wrote: > >> Olaf, what version of patch are you using? > > Mostly 2.7.x, but also add 2.5.x to the mix. > So far I did not try what the tools dealing with the resulting patch > file would actually do with such a stripped down variant.
I think the way to go is --no-renames until you stop using patch <2.7. If you don't want to specify it each time, you can revert to the pre-2.9 behavior by setting
[diff] renames = false
in ~/.gitconfig.
-- Matthieu Moy http://www-verimag.imag.fr/~moy/