InvalidGitRepositoryError when calculating last_site_revision_timestamp (conflict with monorepo plugin)

[tcardonne]

Hello,

The plugin throws an InvalidGitRepositoryError when used with the monorepo-plugin (which is wrapped in backstage/mkdocs-techdocs-core.

The code throwing the error seems to be the calculation of the last_site_revision_timestamp in

mkdocs-git-revision-date-localized-plugin/mkdocs_git_revision_date_localized_plugin/plugin.py

Lines 70 to 72 in 9cfce40

	self.last_site_revision_timestamp = self.util.get_git_commit_timestamp(
	config.get('docs_dir')
	)

Because the monorepo plugin changes the docs_dir to a temporary folder, no parent folder contains the git directory.

It seems #41 fixed this issue for the last revision date of individual pages but the calculation of last site revision date was added after.

I can work on a fix for this but I'm not sure how we could restore the original docs_dir to calculate the last_site_revision_timestamp.
Would you have any idea ?

Thanks !

[timvink]

Good find, thanks for reporting!

Because the monorepo plugin changes the docs_dir to a temporary folder, no parent folder contains the git directory.

That's indeed the cause. I've worked on this before (see backstage/mkdocs-monorepo-plugin#13).

Changing the order of the plugins to have this plugin first should give us access to the docs_dir before it was changed.

plugins:
  - git-revision-date-localized
  - monorepo

I originally had that check here also, but after not using the docs_dir anymore (because I can access the original location of each file through the abs_file_path attribute), the order did not matter.

There's multiple original docs_dirs going into a single docs_dir (in /tmp), so we would need all of them to be able to check the most recent edit.

I thought we might be able to loop over all the files during the on_files() event (see https://www.mkdocs.org/dev-guide/plugins/) and figure out the latest revision. But for monorepo those files will all be in the /tmp folder, so no revision date.

If we enforce monorepo to load before this plugin, and somehow figure out how to use it's internal plugin attributes, we might be able to work something out. these look promising.

Ideas?