Date: Wed, 15 Apr 2015 05:46:32 -0400 From: "Mikhail T." <mi+thun@aldan.algebra.com> To: Alexey Dokuchaev <danfe@FreeBSD.org> 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) Message-ID: <552E3378.1020602@aldan.algebra.com> In-Reply-To: <20150415091905.GB50397@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?552E3378.1020602>