src/usr.bin/patch/pch.c, branch stable/14 FreeBSD source tree patch: Support long context lines. 2024-02-24T12:12:49+00:00 Dag-Erling Smørgrav des@FreeBSD.org 2024-02-12T18:26:13+00:00 4ffc5ab03f8370dcffb1d0bb968e2152348cc709 MFC after: 1 week Sponsored by: Klara, Inc. Reviewed by: allanjude Differential Revision: https://reviews.freebsd.org/D43850 (cherry picked from commit 851a9da38f070675c42a6d69c41c47a5d29ee3d0) 
MFC after:	1 week
Sponsored by:	Klara, Inc.
Reviewed by:	allanjude
Differential Revision:	https://reviews.freebsd.org/D43850

(cherry picked from commit 851a9da38f070675c42a6d69c41c47a5d29ee3d0)
Remove $FreeBSD$: one-line .h pattern 2023-08-16T17:54:23+00:00 Warner Losh imp@FreeBSD.org 2023-08-16T17:54:23+00:00 42b388439bd3795e09258c57a74ce9eec3651c7b Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/ 
Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/
patch: don't run off the end of path if it ends in '/'. 2023-08-07T03:27:27+00:00 Pedro F. Giffuni pfg@FreeBSD.org 2023-08-07T03:27:27+00:00 9610cbc09e72c370369b5cc0e165542a2c5fdca7 Found by fuzzing (afl) in OpenBSD. Obtained from: OpenBSD (CVS 1.65) 
Found by fuzzing (afl) in OpenBSD.

Obtained from:	OpenBSD (CVS 1.65)
patch: cleanup variable initialization a bit. 2021-07-22T19:23:22+00:00 Pedro F. Giffuni pfg@FreeBSD.org 2021-07-22T19:09:17+00:00 c384a27805a630ae45ca3d97614a07ebfce5515d musl libc fgetln is a bit more pickier. Hinted by: chimera-linux (git 31491e1de2e1241885984cd9e4b978965f14eda4) 
musl libc fgetln is a bit more pickier.

Hinted by:	chimera-linux (git 31491e1de2e1241885984cd9e4b978965f14eda4)
Remove heuristic for dealing with trailing newlines being truncated by mailers. 2020-08-16T23:55:23+00:00 Warner Losh imp@FreeBSD.org 2020-08-16T23:55:23+00:00 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 
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
patch(1): give /dev/null patches special treatment 2019-11-04T03:07:01+00:00 Kyle Evans kevans@FreeBSD.org 2019-11-04T03:07:01+00:00 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 
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
patch(1): Exit successfully if we're fed a 0-length patch 2019-03-01T01:20:21+00:00 Kyle Evans kevans@FreeBSD.org 2019-03-01T01:20:21+00:00 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 
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
patch: further cleanup to git-style diffs. 2017-12-21T16:25:33+00:00 Pedro F. Giffuni pfg@FreeBSD.org 2017-12-21T16:25:33+00:00 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) 
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 cases 2017-10-09T14:50:02+00:00 Kyle Evans kevans@FreeBSD.org 2017-10-09T14:50:02+00:00 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 
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:30+00:00 Pedro F. Giffuni pfg@FreeBSD.org 2017-07-02T21:00:30+00:00 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) 
Sometimes patches coming from other places have extra a/ and b/
directories prepended to filenames.

Obtained from:	OpenBSD (CVS rev. 1.57, 1.58)