Suhail Singh <suhailsingh...@gmail.com> writes: > Ihor Radchenko writes: > >> I am a bit confused. What do you mean by "git author date" and "git >> commit date"? > > In the output of `git log --pretty=fuller`, there is AuthorDate which is > distinct from CommitDate. In case unfamiliar, an elaboration on the > distinction: <https://stackoverflow.com/a/11857467>.
I see now. But do you actually use one but not other in practice? >> I think that we should use an alternative approach. Both "git time" and >> "fs time" are only an approximation. The true decision to re-publish an >> article should be triggered by article text being modified. So, we may >> better decide based on the file text hash, not the modification times. > > For it to work, the "file text hash" would have to also take into > account the "file text hash" of included files, or the decision to > re-publish would have to be predicated on the hash of included files as > well. I.e., the equivalent of this logic in > org-publish-cache-file-needs-publishing : > > (let ((mtime (org-publish-cache-mtime-of-src filename))) > (or (time-less-p pstamp mtime) > (cl-some (lambda (ct) (time-less-p mtime ct)) > included-files-mtime))) And the code right above the quoted already looks into INCLUDEs. It should not be too hard to add buffer hash calculation there. > But assuming the existence of equivalent logic, yes something like a > file hash would work. In fact, at least in the case of git, the VCS > could even be queried for it (via git hash-object). Probably an overkill. It will only work for files without includes and force us to use exactly the same hash algorithm. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
