svn commit: r540489 - in head/devel/fhist: . files

[Kyle Evans]

\On Fri, Jun 26, 2020 at 8:59 AM Alexey Dokuchaev <danfe at freebsd.org> wrote:
>
> On Fri, Jun 26, 2020 at 03:47:52PM +0200, Mathieu Arnold wrote:
> > On Fri, Jun 26, 2020 at 01:38:11PM +0000, Alexey Dokuchaev wrote:
> > > On Fri, Jun 26, 2020 at 03:28:41PM +0200, Mathieu Arnold wrote:
> > > > On Fri, Jun 26, 2020 at 12:41:05PM +0000, Alexey Dokuchaev wrote:
> > > > > ...
> > > > > Please, "svn revert" patches which forwent no functional changes prior
> > > > > to making commit.  It just clutters the diff and decreases SNR. :-(
> > > >
> > > > In that particular case, it was correct to commit the patch, it has
> > > > functional change, the range information changed
> > >
> > > I see only patch header change, and I'm pretty sure the old patch would
> > > apply just fine (if by "range information" you mean the line address).
> > >
> > > Generally, patch(1) does fuzzy application very well, which allows to
> > > carry patches unmodified literally forever (until patched file changes
> > > enough so the patch no longer applies).
> > >
> > > If you were talking about something else, please be more specific.
> >
> > I was talking about the range information, yes, the line numbers.  It is
> > true that patch(1) does fuzzy patching, and it did when it applied that
> > patch.  The committer then checked that it was still building correctly,
>
> More accurately put, checking that fuzzy application DTRT is what needs
> to be checked.
>

With my "have worked on patch(1)" ballcap on, you understand how patch
fuzzing works, right? The very *definition* of fuzzing in patch(1) is
not doing the right thing, because it's ignoring patch context.

In my ideal world, the ports tree would run with -F0 because it's
absolutely nonsensical to let it look like it might have done the
right thing. No one is going to check that the result is actually
correct, just that it compiles. These are not the same thing.

Thanks,

Kyle Evans