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
210 stars 45 forks source link

`"WARNING - [git-revision-date-localized-plugin] 'C:\Path\To\File.md' has no git logs, using current timestamp"` #151

Closed rmscode closed 1 month ago

rmscode commented 1 month ago

This may not be the correct place to post this issue, but I really don't know where to start. I'm not super familiar with git and what not.

I have two files that make the plugin produce this warning consistently. It does not matter if make and commit new changes . . . there never seems to be any git logs.

rmscode commented 1 month ago

I posted too soon. I found #54 and also this stack exchange post.

It made me realize that this issue started after I changed the name of a dir from upper to lower. Changing the dir back to upper allowed me to see the git logs for the files within, but it wasn't a change that I could commit. I guess since it was the same name, just a different case, git didn't consider it to be a change?

Anyway, what I ended up doing was:

The git logs are back!

timvink commented 1 month ago

I actually released a new version 1 hour ago, that uses git log --follow by default. Are you using the new version already? See https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/releases/tag/v1.3.0

That new version should follow if you move files and should ignore renames as a revision date (and white spaces and blank lines) when determining the last revision date with git.

So basically you avoided doing a rename at all?

timvink commented 1 month ago

So if you were using the new version, I would really like to have a minimal example. Don't want to have a broken version released :)

rmscode commented 1 month ago

I actually released a new version 1 hour ago, that uses git log --follow by default. Are you using the new version already? See https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/releases/tag/v1.3.0

That new version should follow if you move files and should ignore renames as a revision date (and white spaces and blank lines) when determining the last revision date with git.

So basically you avoided doing a rename at all?

I am not using the new version. I don't think this issue was with your plugin as much as it was with git or something I did with git. I say that because git log with and without --follow did not produce logs for me until I took the steps I mentioned above.

Originally, I created a directory named UPS in my docs and added some new files there. I made some commits to those files and then decided later to rename that directory to ups. I did this inside VSCode. Looking back through my commit history just now (I use GitHub Desktop), I do not see a commit that includes that change. This morning, I noticed that git/GitHub Desktop wasn't picking up when I changed the case. That's why I added a character to change the name completely (UPS-), committed that, and then committed another change (ups) right afterward.

Along the way, I had an issue where I lost a stash and recovered that work in an unconventional way. I can't recall how I did that, but I'm thinking it has something to do with this whole fiasco. VSCode opened a diff when I tried to save changes to the files afterward, saying something about older unsaved changes. It was a mess.

timvink commented 1 month ago

Thanks for explaining! And no doesn't seem related to this plugin.

Git is hard. Here's a fun one to bookmark btw 😀https://ohshitgit.com/

rmscode commented 1 month ago

No problem. Thanks for the link!