Re: [RFC] patch's default backup behavior

On Mon, Apr 11, 2022 at 12:07 PM Kyle Evans <kevans@freebsd.org> wrote:
>
> On Mon, Apr 11, 2022 at 11:59 AM Rodney W. Grimes
> <freebsd-rwg@gndrsh.dnsmgr.net> 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.
> >
> > Personally, if YOU like the behavior of gnu patch, by all means,
> > please USE gnu patch.  Please do NOT make bsd patch behave in
> > a different manner simply because you personally like that
> > other behavior.
> >
> > If you want the stuff to look like Linux/GNU by all means,
> > go RUN linux/gnu!!!!
> >
>
> Your response is completely missing the point, and could have been omitted.
>

This response was unnecessarily short. I'll expand on that, to be constructive.

If you re-read the original e-mail, including the subject line, this
is a 'request for comments'. I'm trying to assess the social and
technical hurdles to something like this, as well as gauge the
community interest. Userbases evolve, software evolves, peoples' needs
evolve, all over time -- assessing this kind of stuff over time is a
useful exercise.

I expressed my preference and requested others' commentary. In return,
I've received a mixed split of opinion, and I've received some
technical issues as well. We've had a relatively healthy discussion,
and as a result this change will likely not happen.

What's not helpful is e-mails like the above, which simply attacked my
position while adding nothing of value to the discussion. This kind of
attack has no place in a healthy discussion, and I would encourage you
to refrain from doing that in the future.

Thanks,

Kyle Evans