Re: [RFC] patch's default backup behavior
- Reply: Cy Schubert : "Re: [RFC] patch's default backup behavior"
- In reply to: Warner Losh : "Re: [RFC] patch's default backup behavior"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 09 Apr 2022 03:44:34 UTC
On Fri, Apr 8, 2022 at 10:41 PM Warner Losh <email@example.com> wrote: > > > > On Fri, Apr 8, 2022, 9:26 PM Kyle Evans <firstname.lastname@example.org> wrote: >> >> Hello! >> >> FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, >> where a backup is created for every file patched. >> >> I'd like to test the waters on switching this to the GNU behavior, >> which feels a whole lot more reasonable. Notably, they'll only create >> backup files if a mismatch was detected (presumably this means either >> a hunk needed fuzz or a hunk outright failed). This yields far fewer >> backup files in the ideal scenario (context entirely matches), while >> still leaving backup files when it's sensible (base file changed and >> we might want to regenerate the patch). >> >> Thoughts / comments / concerns? Cross-posted this to a couple of >> different lists to try and hit the largest number of stakeholders in >> patch(1) behavior. > > > Could one select the old behavior? Or would it just be a change? A new -V value? > Yeah, the current behavior is actually represented by the `-b` flag. With the new behavior, we'd specifically implement `--backup-if-mismatch` (a nop from the beginning), `--no-backup-if-mismatch` (turn off backups, equivalent to `-V none` but "lighter" in that it won't override -b/-V) and we'd leave existing flags otherwise alone. > I like the Idea. > > Warner > >> Thanks, >> >> Kyle Evans >>