build: bump mkdocs-git-revision-date-localized-plugin from 1.5.3 to 1.6.0

[dependabot]

Bumps mkdocs-git-revision-date-localized-plugin from 1.5.3 to 1.6.0.

Release notes

Sourced from mkdocs-git-revision-date-localized-plugin's releases.

v1.6.0

Highlights

Faster builds

Every page asked git which tag pointed at its commit, and asked again for the site-wide revision commit — the same answer, recomputed for each page. Those lookups are now cached.

The bigger your site, the more you save: on a 1000 page site this removes roughly 18 seconds of build time.

custom_format keeps your own words

If your format had any text around the date directives, that text came out scrambled:

custom_format: "Updated on %d %B %Y"

before:   Up23AMt723 on 23 January 2022
now:      Updated on 23 January 2022

Any format that was made up purely of % directives (including the %d. %B %Y default) was unaffected and still renders exactly as before. Unrecognised directives such as %Q are now left alone instead of being quietly reinterpreted as a different date field.

Creation date commit hash and tag now work

page.meta.git_creation_date_localized_hash and page.meta.git_creation_date_localized_tag were documented but always came back empty. If you use them in a theme override to link back to the commit or release that introduced a page, they now contain what you expect.

Shallow clone warnings reach more setups

The warning that tells you your dates will be wrong because CI only fetched part of the history was silently skipped whenever your .git was not in the directory you ran mkdocs from — a repository inside docs/, or a temporary checkout made by plugins such as monorepo. It now fires there too.

Clearer messages when something goes wrong

• A bad type: now produces a proper MkDocs config error listing the valid values, instead of a bare AssertionError.
• If reading git history in parallel fails, the error explains what enable_parallel_processing: false actually does, rather than suggesting a fallback it never attempted.
• Plugin messages now go through MkDocs' own logger, so they are formatted and coloured like every other message in your build output.

Type hints are now visible

The package ships py.typed, so mypy, pyright and ty can see the plugin's annotations.

Upgrading

mkdocs build --strict is now stricter. Warnings from this plugin previously bypassed MkDocs' warning counter, so --strict ignored them. They now count.

In practice this means a build that combines --strict with a shallow clone will start failing where it used to pass — most commonly GitHub Actions, which checks out with fetch-depth: 1 by default. The dates in that build really are wrong, so the right fix is to fetch the full history:

- uses: actions/checkout@v6
</tr></table> 

... (truncated)

Commits

• 8db2449 Bump version to 1.6.0
• 1f6eb6d Merge pull request #226 from timvink/refactor/page-rendering-and-packaging
• 604005a Merge pull request #224 from timvink/fix/date-formatting-and-git-detection
• 6e9e4e4 Cache tag lookups, split up on_page_markdown, tidy packaging
• bf270f7 Fix custom_format literals, creation commit hash and shallow clone detection
• 97ecbac Bump mkdocs-material from 9.7.6 to 9.7.7 (#223)
• a2313a3 Bump version to 1.5.4
• b1be777 Bump pymdown-extensions from 11.0 to 11.0.1 (#221)
• fd6e3b0 Bump gitpython from 3.1.57 to 3.1.58 (#220)
• 0c308d5 Bump gitpython from 3.1.54 to 3.1.57 (#219)
• Additional commits viewable in compare view

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud