timvink / mkdocs-git-revision-date-localized-plugin

MkDocs plugin to add a last updated date to your site pages
https://timvink.github.io/mkdocs-git-revision-date-localized-plugin/index.html
MIT License
193 stars 39 forks source link

Feature Request: print git error explicitly #98

Open ldeluigi opened 1 year ago

ldeluigi commented 1 year ago

https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/blob/9cfce40942c83dd15834fb879caa4171a426ecdd/mkdocs_git_revision_date_localized_plugin/util.py#L127

When an error occurs with git commands, I can't debug the reason.

For example, I can't distinguish between:

  1. git is not installed
  2. not a git repo
  3. git repo is corrupted
  4. git repo owner forbids commands
  5. other

PS. I'd like the same thing for your others git-based mkdocs plugins

timvink commented 1 year ago

That's strange, as the actual error is re-raised:

https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/blob/9cfce40942c83dd15834fb879caa4171a426ecdd/mkdocs_git_revision_date_localized_plugin/util.py#L139

Git errors come from the GitPython dependency, and are raised as-is. I don't have their error handling top of mind -- but perhaps you can create a reproducable example and open an issue there?

timvink commented 1 year ago

@ldeluigi small reminder. Can you provide some more details?

ldeluigi commented 1 year ago

@ldeluigi small reminder. Can you provide some more details?

Yes. I'd like to see the git error even if I enabled fallback_to_build_date. The raise instruction is done only in the else part of the catch clause.

I'd like to see a info message that explains why git fired the error...

ldeluigi commented 1 year ago

The problem is that I enabled that option only for when a git repo doesn't exist at all. When it does, if something goes wrong, I want to fallback to build date + see what went wrong....

Could you add some code that checks if a .git folder is present and in that case you primt debug info on the git exception?

timvink commented 1 year ago

Ahhh, I see! Thanks for clarifying, and yes, logging the error when there's a fallback makes sense. Probably a warning level log is more fitting than a info level log.