From owner-svn-ports-head@FreeBSD.ORG Tue Apr 14 17:51:27 2015 Return-Path: Delivered-To: svn-ports-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA451C09; Tue, 14 Apr 2015 17:51:26 +0000 (UTC) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 6AF3C6AE; Tue, 14 Apr 2015 17:51:25 +0000 (UTC) X-Auth-ID: anat Received: from devlanhide.timeinc.net (HELO utka.zajac) ([209.251.200.245]) by smtp02.lnh.mail.rcn.net with ESMTP; 14 Apr 2015 13:51:26 -0400 Message-ID: <552D539D.4040800@aldan.algebra.com> Date: Tue, 14 Apr 2015 13:51:25 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexey Dokuchaev CC: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: On the "makepatch" target (Re: svn commit: r384004 - head/security/pecl-crack/files) References: <201504141624.t3EGO1xY065515@svn.freebsd.org> <20150414162951.GA10928@FreeBSD.org> <552D47CF.6090604@aldan.algebra.com> <20150414170911.GA25041@FreeBSD.org> In-Reply-To: <20150414170911.GA25041@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.20 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: Tue, 14 Apr 2015 17:51:27 -0000 On 14.04.2015 13:09, Alexey Dokuchaev wrote: > The point is to avoid useless noise in the diff. "Statistics" you're > talking about is pretty meaningless indeed, and since each next careless > submitter will probably overwrite it with their own timezone makes it > even more meaningless. The next careless submitter would have to be patching the same file -- which does not happen very often. But I understand your point as far the as timestamp on the /original/ file goes. I just tried using the target and found, that I dislike it for the following reasons: * It retains the .orig suffix in the diff -- a completely useless 5 bytes carrying no information; * It discards the timestamp of the new version of the patched file, throwing out not only the timezone, but the actual time the work was done; * It creates, mechanically, one patch per file -- whereas I, for one, often prefer to group related changes to multiple files into a single patch (makes it easier to refer upstream maintainers to the patches); * The new patchs' names retain extensions of the patched files, such as, for example patch-crack.c. This confuses various tools, which treat files based on extensions like cscope or mantis bug-tracker, which, in this example, treat it like C-source, rather than a patch. Yours, -mi