Re: Last modification date of the document with git?

[Gavin Smith]

On Fri, Oct 1, 2021 at 4:47 PM Vivien Kraus via Users list for the
Texinfo documentation system <help-texinfo@gnu.org> wrote:
>
> Dear texinfo hackers,
>
> I’m currently developing my own package with git, and build it with GNU
> Guix.
>
> Both git and guix won’t care about the modification dates of my files.
> Git will override it when I check out some commit, and git clone won’t
> preserve the modification date. Guix will even reset it to Jan 1st
> 1970, because random dates may harm reproducibility if they depend on
> the current date.
>
> Since I use automake, the file last modification date is unfortunately
> the date used to indicate the last modification of the document. So, it
> is very imprecise to use, and won’t survive a git clone.
>
> However, git can tell me what commit modified the document, and from
> that I can take the (author, or maybe commit?) date. It should be a way
> better approximation of the true date of last modification.
>
> There are two problems with this approach: if the git clone used to
> build the project is shallow (this is the case with Guix, for
> instance), I won’t be able to get a useful git log. Also, it’s quite
> hard to change the way Automake computes the modification date (I could
> do without the version.texi automake trick though).
>
> I imagine a lot of texinfo users actually use git. Actually, texinfo
> devs *themselves* use git to maintain a texinfo document (the texinfo
> manual). I see from the texinfo source that they use the version.texi
> Automake trick, and I expect others to do so too. How do you tackle
> this issue? Do you just hope nothing "touches" your texi files on your
> hard drive?

I don't understand why you think there is an issue with "git clone".
As the Info files that are built from Texinfo files are not in the git
repository, after the repository is cloned the Info files are still to
be built.

It makes perfect sense for the date of the file on your hard disk to
be the date the file was updated on your hard disk and not the date of
the commit. Suppose you check out an old version with "git checkout".
Updating the file modification times to the present time means that
any derivative files will be regenerated by the build system. This is
the same for any source code stored in git. Generally derived files
are not kept in the git repository, to avoid problems with file
modification dates.

One option (which I haven't used myself much) for exploring old
versions in the git history, without losing all the built files from
the latest version, is to use a separate git checkout for this.