Date: Thu, 16 Apr 2015 01:56:43 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: "Mikhail T." <mi+thun@aldan.algebra.com> 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: <20150416015642.GA96530@FreeBSD.org> In-Reply-To: <552E3378.1020602@aldan.algebra.com> 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> <552E3378.1020602@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 15, 2015 at 05:46:32AM -0400, Mikhail T. wrote:
> > 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.
*sigh*. No, I'm not contradicting or arguing with myself. Again, try to
pay attention:
- new (patched, ^+++) file mtime change frequently; original file mtime
is "set" by upstream and should be kept the same during the patch life
span in the ports tree;
- because original (^---) mtime is a non-volatile thing, it can be kept
in the patch, because it 1) can be useful; and 2) does not pollute the
diff during patch updates, that is, ^--- line does not change;
- because file mtime change frequently, it would pollute the diff if we
keep it there; and even if we don't keep it, "time of work" is pretty
much the same as time of the commit (just do "log -l1" on the patch
to obtain time of work); you cannot ask svn to give you the an idea
of mtime of the original (^---) file.
> 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...
We're not talking about what, generally, "patch-foo.c" file looks like.
We're talking about FreeBSD ports patch files under files/.
I think that the reason why we name our patches as "patch-foo_bar.c" but
not "foo_bar.c-patch" like e.g. RedHat does, is because of the "patch-aa"
legacy. Since those patch-XX files did not have extension, it was not a
problem. When we switched (for the better) to include filename in the
patch name, because of "patch-" prefix (vs. "-patch" or "-diff" suffix)
file extension was not concealed. Fixing it by renaming all the patches
seems unwarranted, though.
> 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...
My point is not to pressure you, however gently, to use makepatch; all I
want is to prevent useless noise appear in the commit diffs.
./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150416015642.GA96530>