Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relying on filesystem dates is a bad idea #21

Open
kevinrenskers opened this issue Nov 19, 2024 · 2 comments
Open

Relying on filesystem dates is a bad idea #21

kevinrenskers opened this issue Nov 19, 2024 · 2 comments

Comments

@kevinrenskers
Copy link
Member

Currently Saga reads the file's creation and last modified dates, and stores those into the Item. The dates are then used inside of the atom feed generation for example. But the creation date is also the fallback for the published date: if you don't include a date field in your markdown metadata then the published date is set to the file creation date.

This is a problem because the file creation date is not stored in git, and when you do a fresh checkout the file creation date is set to "right now" instead of the actual past creation date. This is also a problem on my own website. While I do override the published date to something consistent, the last modified date is used in the atom feed.. and these dates just keep on changing because Netlify fetches the repo and the dates change.

Basically, using file attributes doesn't seem like a good idea?

On the other hand, this is not a problem with Saga but a problem with git. For people who don't store their website in git or who create the static sites on their own computer, this wouldn't be a problem. So maybe it would be better to add something to the Saga docs about this?

See also https://stackoverflow.com/questions/1964470/whats-the-equivalent-of-subversions-use-commit-times-for-git:

Each time I clone my repository, I want the timestamps of files to reflect when they were last changed in the remote repository, not when I cloned the repository.

@kevinrenskers
Copy link
Member Author

It seems that git-restore-mtime could solve the file modification date issues. This is not installed on Netlify, I've sent them a feature request.

I think this should be added to the documentation, so that people at least are aware of the behavior of the file attributes not being reliable.

kevinrenskers added a commit to loopwerk/loopwerk.io that referenced this issue Nov 20, 2024
@kevinrenskers
Copy link
Member Author

OK this totally works 🎉
loopwerk/loopwerk.io@e94cb85

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant