svn commit: r491675 - in head/comms/fldigi: . files

[Alexey Dokuchaev]

On Thu, Jan 31, 2019 at 08:19:48AM -0600, Kyle Evans wrote:
> On Thu, Jan 31, 2019 at 8:10 AM Alexey Dokuchaev <danfe at freebsd.org> wrote:
> > On Thu, Jan 31, 2019 at 08:37:32AM -0500, Diane Bruce wrote:
> > > On Thu, Jan 31, 2019 at 02:14:39AM +0000, Alexey Dokuchaev wrote:
> > > > ...
> > > > These two patches were essentially not changed and should have been
> > > > dropped from the commit batch to reduce repo churn and diff noise.
> > >
> > > Tell that to the make makepatch maintainers please.
> >
> > Well, no: makepatch would never (and it's not supposed to) be so smart
> > to detect/mitigate these things.  Evaluating a diff (and commit hygiene
> > in general) is committer's responsibility.
> 
> It's worth noting that I added some bits [1] to makepatch to try and
> help reduce some churn by blatantly ignoring new patches that resulted
> in only change to the timestamp.

As an author of the first `makepatch' implementation, I have mixed
feelings about current, more and more smart implementation, but of
course I appreciate the improvements Kyle.

> I think there's no reason this couldn't grow the ability to ignore
> changes like the ones you pointed out if you make sure it's still
> sensitive to the line offset information [...]

Generally, patch(1) had always allowed a bit of a slack and inaccuracy
in the context and line numbers, which differs between implementations:
one can have a gpatch-eatable patch that our patch(1) would choke on.

There's always a trade-off between keeping patches 100% accurate and
cleanness of the commit diff.  Since I'm comfortable with the patch(1)
and thus able to deal with occasional bursts of the techdebt, I tend
to value diff cleanness way more. :-)

./danef