FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F13.4 2023-08-23T17:43:32Z 2023-08-23T17:43:32Z Warner Losh imp@FreeBSD.org 2023-08-22T01:32:13Z urn:sha1:24115b70d6d614ed7ac5cfc4f51fa9d6cfe8b1b2 Remove /^\.\\"\s*\$FreeBSD\$$\n/ Similar commit in main: (cherry picked from commit b2c76c41be32) 2023-08-23T17:43:30Z Warner Losh imp@FreeBSD.org 2023-08-22T01:32:01Z urn:sha1:023fc80ee38a117fa65b2ccb2abf8bdc7dbd6fd9 Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/ Similar commit in main: (cherry picked from commit d0b2dbfa0ecf) 2023-08-23T17:43:22Z Warner Losh imp@FreeBSD.org 2023-08-22T01:31:13Z urn:sha1:34041aac835a0bce462bccb7e0239c0ba092f872 Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/ Similar commit in main: (cherry picked from commit 42b388439bd3) 2023-07-25T15:13:49Z Warner Losh imp@FreeBSD.org 2023-05-10T15:40:58Z urn:sha1:caa41f641755c935b036e17440a3b49329c904ed The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix (cherry picked from commit 4d846d260e2b9a3d4d0a701462568268cbfe7a5b) 2023-02-16T03:29:40Z Kyle Evans kevans@FreeBSD.org 2023-01-24T16:46:01Z urn:sha1:dfdc3b2e6541c941b51edd5e5ec575411e5be143 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. (cherry picked from commit 7e688ed493482c5346d969e7667856d8ced8d87a) 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.