Fix spelling of 'fallback_to_build_date' in logs

[biochimia]

No description provided.

[timvink]

Good catch, thanks for the contribution!

I wouldn't expect these warnings/errors to occur very frequently. Can I ask how you found these, what's your use case?

I'm still not 100% happy with the fallback to build date solution when git is not available. Any thoughts? Was the behaviour at least sufficiently clear?

Will release in the next version, not planned yet..

[biochimia]

I bumped into this while setting up the structure for a new mkdocs documentation project. As there were no commits in the project, I expected the plugin to use the fallback and noticed the disconnect between the logged message and your documentation.

In my case, I understood the expected behaviour. We use a custom mkdocs setup internally, and had previously implemented the query from git behaviour with no fallback. When we switched to shallow project clones, we gave up the timestamp.

Browsing our documentation sites, and absent a better freshness measure, I think it's still useful to have the build date available, so some measure of staleness is visible in the pages. It has the downside of not representing the content, on the other hand projects that are alive are also more likely to keep documentation up to date.

One thing I miss is a label to clearly represent the meaning of the date: "Last built on" vs "Last edited on", but this requires more coordination with the theme. One thing to consider is to make a single build date across all pages, but I don't expect that this would be noticeable anywhere 🙂.

[timvink]

Thanks for clarifying!

I agree build_date should be a separate tag, to make things more explicit. I created #28 for this, although I will first work on merging this plugin with another git plugin (see #29).