FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.4 2021-05-16T04:42:02Z 2021-05-16T04:42:02Z Xin LI delphij@FreeBSD.org 2021-05-02T16:27:32Z urn:sha1:cd7d1862f7b07277577d1e684792526acfdd3bc7 (cherry picked from commit 9769f6f808210ddc304bc9e3c55121e6ce4d9075) 2020-12-27T12:39:57Z Gordon Bergling gbe@FreeBSD.org 2020-12-19T13:00:17Z urn:sha1:fccec952f9b295d8166510533762e0874df9bebf - no blank before trailing delimiter (cherry picked from commit a2f1c81b286c528a8efedf224a13e476dba1de42) 2020-09-09T22:42:14Z Warner Losh imp@FreeBSD.org 2020-09-09T22:42:14Z urn:sha1:70af721dfa52f10203eab437aa9c5939a4177c5d r364291 | imp | 2020-08-16 17:55:23 -0600 (Sun, 16 Aug 2020) | 33 lines Remove heuristic for dealing with trailing newlines being truncated by mailers. ... 2019-12-03T18:55:09Z Kyle Evans kevans@FreeBSD.org 2019-12-03T18:55:09Z urn:sha1:be3a0c5043ce6f6dd57ad55276e9b67447be6867 r351836: patch(1): add some basic tests 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) r351866: patch(1): fix the file removal test, strengthen it a bit 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. r354328: patch(1): give /dev/null patches special treatment 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. 2019-04-04T17:21:30Z Kyle Evans kevans@FreeBSD.org 2019-04-04T17:21:30Z urn:sha1:ca2dafdd851c002b7bf2b1e2dadd7ee432712caa 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. 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) 2017-11-22T03:44:19Z Kyle Evans kevans@FreeBSD.org 2017-11-22T03:44:19Z urn:sha1:bc4f0fe3588183058f52c53f9cf59b77e19842db Patches with very little context (-U0 and -U1) could get misapplied if the file to be patched changes and a hunk is no longer applicable. Matching with fuzz would be attempted and default to a match when we unexpectedly ran out of context. This also affected patches with higher levels of context but had limited actual context due to the hunk being located near the beginning/end of file. PR: 74127, 223545 (exp-run) Reviewed by: emaste, pfg Approved by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D12631 2017-11-20T19:49:47Z Pedro F. Giffuni pfg@FreeBSD.org 2017-11-20T19:49:47Z urn:sha1:8a16b7a18f5d0b031f09832fd7752fba717e2a97 Mainly focus on files that use BSD 3-Clause license. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point.