From owner-svn-ports-all@FreeBSD.ORG Wed Apr 15 10:47:09 2015 Return-Path: Delivered-To: svn-ports-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 998A4397; Wed, 15 Apr 2015 10:47:09 +0000 (UTC) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E1C0945; Wed, 15 Apr 2015 10:47:09 +0000 (UTC) Received: from [192.168.1.8] ([108.53.86.243]) by vms173003.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.34.0 64bit (built Oct 14 2014)) with ESMTPA id <0NMU00J1KDTKY330@vms173003.mailsrvcs.net>; Wed, 15 Apr 2015 04:46:37 -0500 (CDT) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=CJmdhqvG c=1 sm=1 tr=0 a=OxtTj1AvBIaAxO256ZN+aQ==:117 a=3WGNbyozUhgA:10 a=LaogzpLLAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=WVTUJnxFYOcA:10 a=e9J7MTPGsLIA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=gZbpxnkM3yUA:10 a=TD7NeMAxN4OeEBhFkS0A:9 a=pILNOxqGKmIA:10 a=6I5d2MoRAAAA:8 a=E7LBX4UdbKQ0Gl1ZPbIA:9 a=kJeL23yHT1K8UJ-W:21 a=_W_S_7VecoQA:10 Message-id: <552E3378.1020602@aldan.algebra.com> Date: Wed, 15 Apr 2015 05:46:32 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; 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: Re: 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> <552D539D.4040800@aldan.algebra.com> <20150415091905.GB50397@FreeBSD.org> In-reply-to: <20150415091905.GB50397@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-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 10:47:09 -0000 On 04/15/15 05:19, Alexey Dokuchaev wrote: > * It retains the .orig suffix in the diff -- a completely useless 5 bytes > carrying no information; > suffix is traditionally used, and as long as it stays the same, there is no > problem to really talk about. In fact, most people prefer suffixed form, > and it helps to navigate large patches quickly (eye is trained to recognize > common substring), search for it, etc. Except it is not the same. Patches produced by svn diff or git diff do not have it (thankfully). One's eye and the fingers would be better trained to search for ^--- instead of \.orig. > * 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; > Correct. Keeping timestamp of the new file makes no sense -- not due to the > simple fact that every time you touch the file, mtime will be different -- > but also because in the vast majority of cases "the actual time the work was > done" == time of commit with more than good enough precision. > > Keeping mtime of the source file can, in fact, be helpful -- it can give you > an idea of that compilers, operating systems, C++ standards, etc. existed at > the time of work; it helps to "link" the patch to the particular version of > the code it was generated against, for example. Your second paragraph seems to argue against your first... The same arguments -- very well phrased -- apply to usefulness of mtime of both the original and the patched replacement. >> * 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. > I don't see a problem here. Mantis (and others) should be fixed to either > detect the contents or allow to specify that "files/patch-*" is a patch, > (ir)relardless of the extension. I doubt, you'll convince many people, that it is a bug to treat a file named foo.c (or even a patch-foo.c) as a C-source file... To each his own, I suppose -- and I wouldn't have mentioned any of this, if it weren't for the pressure, however gentle, to switch to makepatch in preference of hand-crafting my diffs... Yours, -mi