On the "makepatch" target (Re: svn commit: r384004 - head/security/pecl-crack/files)

[Alexey Dokuchaev]

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