src/usr.bin/patch/patch.c, branch mainFreeBSD source treehttp://cgit.freebsd.org/src/atom?h=main2024-02-12T18:26:13Zpatch: Support long context lines.2024-02-12T18:26:13ZDag-Erling Smørgravdes@FreeBSD.org2024-02-12T18:26:13Zurn:sha1:851a9da38f070675c42a6d69c41c47a5d29ee3d0
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D43850
patch: fix locate_hunk in empty files2023-12-03T17:33:03ZPedro F. Giffunipfg@FreeBSD.org2023-12-03T17:33:03Zurn:sha1:7e8afbb6d605006d7cb867362b225d21c4f5ae57
if `first_guess' is zero then main() assumes that locate_hunk has failed
and aborts the patch operation. Instead, make sure to return 1 (the
line number) so that the patch operation can continue.
Issue originally found by Neels Hofmeyr in the regress suite of the diff
implementation for got, where the tests assume that applying a diff with
`patch' and then again with `patch -R' yields back the original file.
Obtained from: OpenBSD (CVS patch.c,v 1.71)
Remove $FreeBSD$: one-line .h pattern2023-08-16T17:54:23ZWarner Loshimp@FreeBSD.org2023-08-16T17:54:23Zurn:sha1:42b388439bd3795e09258c57a74ce9eec3651c7b
Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/
patch: omit filename if the prompt was ignored2023-02-13T06:15:08ZKyle Evanskevans@FreeBSD.org2023-01-24T16:46:01Zurn:sha1:7e688ed493482c5346d969e7667856d8ced8d87a
When a file is missing, patch(1) will prompt for a filename to try and
patch it. If we're doing a dry-run, we'll output that the patch to the
source file was either ignored/failed. If you ignore the prompt in a
dry-run (i.e. just hit enter), we'll output:
X out of X hunks ignored while patching (null)
Let's improve the aesthetics a bit and just omit the last part if the
prompt was ignored:
X out of X hunks ignored
Unfortunately we can't really test this without expect(1) because both
force and batch mode will use the first best guess, which is wiped out
by the "File to patch:" prompt. We could record the initially derived
bestguess there and use *that*, but given that this is only possible in
an interactive session I think it's fine to just omit the filename
rather than adding a fair amount of complexity (which could also break
other scenarios I haven't considered yet)..
Reviewed by: des
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38179
patch(1): give /dev/null patches special treatment2019-11-04T03:07:01ZKyle Evanskevans@FreeBSD.org2019-11-04T03:07:01Zurn: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
patch(1): Exit successfully if we're fed a 0-length patch2019-03-01T01:20:21ZKyle Evanskevans@FreeBSD.org2019-03-01T01:20:21Zurn: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
patch: rejname[] is also -r option buffer, and should be PATH_MAX.2017-12-21T16:19:10ZPedro F. Giffunipfg@FreeBSD.org2017-12-21T16:19:10Zurn:sha1:c844f14e37e57b9f259fb60423456b297b3951e1
Obtained from: OpenBSD (CVS 1.64)
patch(1): don't assume a match if we run out of context to check2017-11-22T03:44:19ZKyle Evanskevans@FreeBSD.org2017-11-22T03:44:19Zurn: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
Revert r3253652017-11-08T23:11:15ZKyle Evanskevans@FreeBSD.org2017-11-08T23:11:15Zurn:sha1:752e881db7398b10410d26c7d69176ec998d9c3b
r325365 caused several ports to fail to patch correctly. Revert it for the
time being until an exp-run can be completed.
Requested by: antoine
Approved by: emaste (implicit)
patch(1): don't assume a match if we run out of context to check2017-11-03T17:04:30ZKyle Evanskevans@FreeBSD.org2017-11-03T17:04:30Zurn:sha1:ed3b30599370432f6ac501e36099f597f5999d27
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.
PR: 74127
Reviewed by: emaste, pfg
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D12631