Date: Thu, 31 Jan 2019 14:51:51 +0000 From: Alexey Dokuchaev <danfe@freebsd.org> To: Kyle Evans <kevans@freebsd.org> Cc: Diane Bruce <db@db.net>, svn-ports-head@freebsd.org, Diane Bruce <db@freebsd.org>, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: svn commit: r491675 - in head/comms/fldigi: . files Message-ID: <20190131145151.GA77227@FreeBSD.org> In-Reply-To: <CACNAnaH==Qr2se2ebWXo8A%2BGNrnS6iB8PnjWPDwz%2BbJyJaASAw@mail.gmail.com> References: <201901310204.x0V24U5Y032910@repo.freebsd.org> <20190131021439.GA94120@FreeBSD.org> <20190131133732.GA76004@night.db.net> <20190131140956.GA93408@FreeBSD.org> <CACNAnaH==Qr2se2ebWXo8A%2BGNrnS6iB8PnjWPDwz%2BbJyJaASAw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190131145151.GA77227>