Jakob Bohm wrote:
make will still see the files in debian/foo with the
timestamps make expects, and will thus not redo most of the copies and
compilations, as it would if the actual files had been backdated with
touch
I don't see why 'make' would have to redo most of its work with backdating, if
the backdating is done to a time that *could* have been done by a 'make'.
As a thought experiment, suppose your working files are the same as what's in
your repository (i.e., 'git diff' outputs nothing), and suppose you run 'make'
and build everything, and then touch every file that's in the repository so that
its timestamp equals the time of its most recent commit. If the newest such
timestamp is T, suppose you also do a "touch -d T FOO" for every file FOO that's
built by 'make' (i.e., every file that's not in the repository). After these
timestamps are all applied, the resulting set of files should be such that:
1. Running 'make' does nothing because everything appears to be up to date.
2. Putting the files into a tarball and then extracting from the tarball will
still keep 'make' happy on the extracting host.
3. If you redo the whole process you'll still get the same output tarball with
the same time stamps, so it's reproducible.
4. If you change any of the repository-controlled files (either by editing and
committing the results, or by checking out another branch) you redo the whole
process everything will still work with the new configuration (generating
different tarballs of course).
None of this requires --clamp-mtime so I'm not seeing what --clamp-mtime buys
us. Evidently I'm missing something.
