On Tue, Jan 27, Junio C Hamano wrote: > Olaf Hering <o...@aepfle.de> writes: > > > Several files in Documentation have an unstable 'Last updated' timestamp. > > The > > reason is that their mtime changes every time, which prevents reproducible > > builds. > > > > 341 technical/api-index.txt: technical/api-index-skel.txt \ > > 342 technical/api-index.sh $(patsubst %,%.txt,$(API_DOCS)) > > 343 $(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh > > > > 388 howto-index.txt: howto-index.sh $(wildcard howto/*.txt) > > 389 $(QUIET_GEN)$(RM) $@+ $@ && \ > > 390 '$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(wildcard > > howto/*.txt)) >$@+ && \ > > 391 mv $@+ $@ > > > > 399 $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt > > 400 $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \ > > 401 sed -e '1,/^$$/d' $< | \ > > 402 $(TXT_TO_HTML) - >$@+ && \ > > 403 mv $@+ $@ > > All of them seem to have dependencies so it seems to me that two > builds back to back without actually changing their input would not > re-build anything. What am I missing???
Per default the files referenced do not exist, so a build from releases will generate the files. But I agree, perhaps there should be some refactoring to handle dependencies properly. In any case, if the 'Last updated' is unavoidable some reference is required, see my patch in the other mail. > > What file timestamp should be used for them? Likely "../version"? > > I tend to think the "Last updated" timestamp taken from the > filesystem timestamp is a bad practice inherited by these tools from > the days back when nobody used any revision control systems. I'm not sure. The bug is that such 'Last updated' line exists at all in the default output. Noone asked for it, noone really needs it. And it makes it impossible to get reproducible builds. But so far I found no way to avoid the 'Last updated' output. The docs and google suggest something like :last-updated-time!:, which did not work for me. Olaf -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
