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

[Alexey Dokuchaev]

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.

> Now, the patches in the ports tree need to have a correct and coherent
> behavior, and fuzzy patching gets it wrong from time to time.  This is
> why range information is not noise, but important metadata that we
> prefer to be correct all the time.

Well, to your definition of "we". :-)  But I get it: you prefer perfect
patches and noisy commit diffs; I prefer okayish (correctly applicable)
patches and cleaner commit diffs.

./danfe