Re: [RFC] patch's default backup behavior

Am Sun, Apr 10, 2022 at 09:43:41AM -0500 schrieb Kyle Evans:
> On Sat, Apr 9, 2022 at 8:17 PM Joerg Sonnenberger <joerg@bec.de> wrote:
> >
> > Am Fri, Apr 08, 2022 at 10:25:08PM -0500 schrieb Kyle Evans:
> > > 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?
> >
> > Personally, I'm more often annoyed by the GNU behavior than not.
> > Especially when working on pkgsrc, the GNU behavior of
> > sometimes-not-creating-backups actually breaks tooling. I also consider
> > the rationale somewhat fishy as tools like sed have historically not
> > operated in-place.
> >
> 
> To be clear, when you say 'tooling' here, are you referring to pkgsrc
> tooling or random third-party tooling being used as, e.g., build
> dependencies?

pkgsrc tooling, e.g. managing category/package/patches. Similar
questions might exist for FreeBSD ports.

Joerg