Re: [RFC] patch's default backup behavior

From: Cy Schubert <Cy.Schubert_at_cschubert.com>
Date: Sat, 09 Apr 2022 13:06:33 UTC
In message <CACNAnaFi2Ee5M5bX=FoaV-h=nC0kVrpEBqzuyG8SQhJeqkto3g@mail.gmail.c
om>
, Kyle Evans writes:
> On Fri, Apr 8, 2022 at 10:41 PM Warner Losh <imp@bsdimp.com> wrote:
> >
> >
> >
> > On Fri, Apr 8, 2022, 9:26 PM Kyle Evans <kevans@freebsd.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 v
> alue?
> >
>
> 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.

Looks good to me.

>
> > I like the Idea.
> >
> > Warner
> >
> >> Thanks,
> >>
> >> Kyle Evans
> >>
>


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

	The need of the many outweighs the greed of the few.