From owner-svn-ports-head@freebsd.org Fri Jun 26 13:38:12 2020 Return-Path: Delivered-To: svn-ports-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0DFAD358666; Fri, 26 Jun 2020 13:38:12 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49tdHl6df3z4dmb; Fri, 26 Jun 2020 13:38:11 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id D47AA11670; Fri, 26 Jun 2020 13:38:11 +0000 (UTC) Date: Fri, 26 Jun 2020 13:38:11 +0000 From: Alexey Dokuchaev To: Mathieu Arnold Cc: Fernando Apestegu??a , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r540489 - in head/devel/fhist: . files Message-ID: <20200626133811.GA60522@FreeBSD.org> References: <202006261034.05QAYaDe038059@repo.freebsd.org> <20200626124105.GA65385@FreeBSD.org> <20200626132841.kytmjwquonpwkrhr@aching.in.mat.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200626132841.kytmjwquonpwkrhr@aching.in.mat.cc> X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 13:38:12 -0000 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. ./danfe