FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F13.1.0 2021-05-16T04:40:41Z 2021-05-16T04:40:41Z Xin LI delphij@FreeBSD.org 2021-05-02T16:27:32Z urn:sha1:5a485392c4ccc9a9501219f2f52f6a5264658beb (cherry picked from commit 9769f6f808210ddc304bc9e3c55121e6ce4d9075) 2020-12-19T13:00:17Z Gordon Bergling gbe@FreeBSD.org 2020-12-19T13:00:17Z urn:sha1:a2f1c81b286c528a8efedf224a13e476dba1de42 - no blank before trailing delimiter MFC after: 1 week 2020-08-16T23:55:23Z Warner Losh imp@FreeBSD.org 2020-08-16T23:55:23Z urn:sha1:c7cddf955f7a643abe6f999632e005ad9d834885 Every version of patch since the first one posted to mod.sources in 1985 have included a heuristic for coping with the state of email messaging at the time. This heuristic would add up to 4 blank lines to a patch if it thought it needed it. The trouble is, though this causes at least one bug. The bug in my case is that if you have a context diff whose last hunk only deletes 3 or fewer lines, then if you try to reverse apply it with -R, it will fail. The reason for this is the heuristic builds an internal representation that includes those blank lines. However, it should really replicate the lines from the pattern lines line it would any other time, not assume they are blank lines. Removing this heuristic will prevent patch from misapplying the lines removed after applying a 'fuzz' factor to the previous blank line in the file. I believe this will only affect 'new-style' 4.3BSD context diffs and not the older-style 4.2BSD diffs and plain, non-context diffs. It won't affect any of the newer formats, since they don't use the 'omitted' construct in the same way. Since this heuristic was put into patch at a time when email / etc ate trailing white space on a regular basis, and since it's clear that this heuristic is the wrong thing to do at least some of the time, it's better to remove it entirely. It's not been needed for maybe 20 years since patch files are not usually corrupted. If there are a small number of patch files that would benefit from this corruption fixing, those already-currupt patches can be fixed by the addition of blank lines. I'd wager that no one will ever come to me with an example of a once-working patch file that breaks with this change. However, I have 2 patches from the first 195 patches to 2.11BSD that are affected by this bug, suggesting that the relative frequency of the issue has changed signficantly since the original heuristic was put into place. Reviewed by: phk@ Differential Revision: https://reviews.freebsd.org/D26081 2019-11-04T03:07:01Z Kyle Evans kevans@FreeBSD.org 2019-11-04T03:07:01Z urn:sha1:50dacbf6c2a3d32f7e3f20ca98cda23f38817e7f We have a bad habit of duplicating contents of files that are sourced from /dev/null and applied more than once... take the more sane (in most ways) GNU route and complain if the file exists and offer reversal options. This still falls short a little bit as selecting "don't reverse, apply anyway" will still give you duplicated file contents. There's probably other issues as well, but awareness is the first step to happiness. MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D21535 2019-09-05T15:35:57Z Kyle Evans kevans@FreeBSD.org 2019-09-05T15:35:57Z urn:sha1:89b5571e0b4083de499f2b835460349a7c3ebc2c To remain compatible with GNU patch, we should ensure that once we're removing empty files after a reversed /dev/null patch we don't remove files that have been modified. GNU patch leaves these intact and just reverses the hunk that created the file, effectively implying --remove-empty-files for reversed /dev/null patches. 2019-09-05T03:16:14Z Kyle Evans kevans@FreeBSD.org 2019-09-05T03:16:14Z urn:sha1:b27524973cda910697949980e95ad62e5e4be3d1 Summary: - basic: test application of patches created by diff -u at the beginning/middle/end of file, which have differing amounts of context before and after chunks being added - limited_ctx: stems from PR 74127 in which a rogue line was getting added when the patch should have been rejected. Similar behavior was reproducible with larger contexts near the beginning/end of a file. See r326084 for details - file_creation: patch sourced from /dev/null should create the file - file_nodupe: said patch sourced from /dev/null shouldn't dupe the contents when re-applied (personal vendetta, WIP, see comment) - file_removal: this follows from nodupe; the reverse of a patch sourced from /dev/null is most naturally deleting the file, as is expected based on GNU patch behavior (WIP) 2019-03-01T01:20:21Z Kyle Evans kevans@FreeBSD.org 2019-03-01T01:20:21Z urn:sha1:ef30b5a80910bd877f582248004200065eeb3ef5 This change is made in the name of GNU patch compatibility. If GNU patch is fed a zero-length patch, it will exit successfully with no output. This is used in at least one port to date (comms/wsjtx), and we break on this usage. It seems unlikely that anyone relies on patch(1) calling their completely empty patch garbage and failing, and GNU compatibility is a plus if it helps with porting, so make the switch. Reported by: db MFC after: 2 weeks 2018-01-11T15:01:48Z Kyle Evans kevans@FreeBSD.org 2018-01-11T15:01:48Z urn:sha1:21ab148d783814f0157935e3fd210b2f22cdb00f Plan A mmap()'s the entire input file and operates on it in memory. The map(2) call succeeded, so we shouldn't need to bother checking for the NUL byte as long as we're within our buffer space. This was clearly intentional to match "the behavior of the original code", but it creates a discrepancy between Plan A and Plan B that doesn't seem sensible and it's not inherently wrong to allow a NUL byte. This change was motivated by the gemspec in net/rubygem-grpc failing to patch, despite the patch being generated with diff, because a NUL byte was used as a delimiter in the header briefly in an otherwise text file. An alternative was considered: to fallback to plan B if plan A won't process the entire file due to a NUL byte, but I deemed this to be the better option since plan A isn't failing due to memory limitations and will fail later on if it's really dealing with a file it shouldn't be. PR: 224842 (exp-run) Reported by: swills Reviewed by: emaste, pfg MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D13738 2017-12-21T16:25:33Z Pedro F. Giffuni pfg@FreeBSD.org 2017-12-21T16:25:33Z urn:sha1:76df519fe099c90ba2188cd1ca6846181b24b4b2 Fix adding and removing files with git-style a/ b/ diffs: only skip six letters if they actually match "--- a/" and "+++ b/" instead of laxer checks. Obtained from: OpenBSD (CVS 1.59) 2017-12-21T16:19:10Z Pedro F. Giffuni pfg@FreeBSD.org 2017-12-21T16:19:10Z urn:sha1:c844f14e37e57b9f259fb60423456b297b3951e1 Obtained from: OpenBSD (CVS 1.64)