Re: commit 9d0f14

[Ethan M. <eam...@gm...>]

On Thu, Mar 22, 2018 at 8:17 AM, sfeam via gnuplot-beta <
gnu...@li...> wrote:

> On Thursday, 22 March 2018 10:26:33 Mojca Miklavec wrote:
> > On 22 March 2018 at 02:34, Tatsuro MATSUOKA wrote:
> > >  [9d0f14] (HEAD, master) by Ethan A Merritt Ethan A Merritt
> > >
> > > another try at timestamp.h, this time using build date
> > >
> > > The Makefile rule for timestamp.h was broken when we switched from
> > > cvs to git, since it relied on ChangeLog always being current.
> > > Proposed replacement rules have so far failed to work for out-of-tree
> > > builds or builds from a snapshot rather than a full git clone.
> > > This attempt simply uses the current build date, which admittedly may
> > > not be newer than the last-modified date but at least has the virtue
> > > of not depending on git.
>

[snip]


> This whole approach is less satisfactory than the old (CVS) mechanism
> of checking the top of the ChangeLog file.  What I really want, I think,
> is an option attached to the "git commit" command that automatically
> modifies the timestamp file to match the commit date.   The file itself,
> not the metadata.  Something that persists outside of the git context.
>
>         Ethan
>
>
Here's a different idea.
Does git gurantee to preserve the modification date attribute of files in
the repository?
I observe that it does this in practice, but maybe it is not a guarantee.
We don't really need to alter the _contents_ of a timestamp file,  just its
modification date.
So it would be sufficient if there is a way to automate that "git commit"
does a "touch + stage"
on the timestamp file regardless of what files are otherwise in the commit.
The Makefile rule is then dead simple, since checking the modification date
of a file
is exactly what make was designed for.