src/usr.bin/patch/pch.c, branch releng/12.4FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=releng%2F12.42020-09-09T22:42:14ZMFC r364291:2020-09-09T22:42:14ZWarner Loshimp@FreeBSD.org2020-09-09T22:42:14Zurn: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.
...
MFC r351836, r351866, r354328: patch(1) /dev/null testing+improvement2019-12-03T18:55:09ZKyle Evanskevans@FreeBSD.org2019-12-03T18:55:09Zurn: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.
MFC r344677: patch(1): Exit successfully if we're fed a 0-length patch2019-04-04T17:21:30ZKyle Evanskevans@FreeBSD.org2019-04-04T17:21:30Zurn: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.
patch: further cleanup to git-style diffs.2017-12-21T16:25:33ZPedro F. Giffunipfg@FreeBSD.org2017-12-21T16:25:33Zurn: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)
patch(1): Don't overrun line buffer in some cases2017-10-09T14:50:02ZKyle Evanskevans@FreeBSD.org2017-10-09T14:50:02Zurn:sha1:4835edfa0d452a9d75eeb73c3414d563ec9909f9
Patches like file.txt attached to PR 190195 with a final line formed
like ">(EOL)" could cause a copy past the end of the current line buffer. In the
case of PR 191641, this caused a duplicate line to be copied into the resulting
file.
Instead of running past the end, treat it as if it were a blank line.
PR: 191641
Reviewed by: cem, emaste, pfg
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D12609
patch(1): add support for git generated diffs.2017-07-02T21:00:30ZPedro F. Giffunipfg@FreeBSD.org2017-07-02T21:00:30Zurn:sha1:85823a601c1ede44a844edde4f1d18643903ce54
Sometimes patches coming from other places have extra a/ and b/
directories prepended to filenames.
Obtained from: OpenBSD (CVS rev. 1.57, 1.58)
patch: if reading fails, do not go into infinite loop asking for a filename.2017-06-08T03:15:08ZPedro F. Giffunipfg@FreeBSD.org2017-06-08T03:15:08Zurn:sha1:12300d3aa0168f532d29242ce9a47afb630a348c
This can happen if no tty is available.
Obtained from: OpenBSD (CVS rev 1.54)
MFC after: 5 days
Revert r311106:2017-01-02T18:23:31ZPedro F. Giffunipfg@FreeBSD.org2017-01-02T18:23:31Zurn:sha1:4f548c1916e86995b61b678743c91d689bba8581
patch(1): extend the maximum length of a line from USHRT_MAX to UINT_MAX.
This doesn't really work for 32 bit platforms.
Pointed out by: kib
patch(1): extend the maximum length of a line from USHRT_MAX to UINT_MAX.2017-01-02T17:12:14ZPedro F. Giffunipfg@FreeBSD.org2017-01-02T17:12:14Zurn:sha1:ad8469feec8a84469d38b4a1237fd39abea16198
We can handle such "big data" without much trouble.
Try to do a better job at detecting the rejection cause while here.
MFC after: 2 weeks
patch(1): avoid signed integer overflow when debugging.2016-04-24T04:08:36ZPedro F. Giffunipfg@FreeBSD.org2016-04-24T04:08:36Zurn:sha1:2c4eed4723c3a739b85102d1ff911f06fe826fbc
Integer i is used to index p_end of type LINENUM (actually long).
Match the types.
MFC after: 5 days