-
-
Notifications
You must be signed in to change notification settings - Fork 385
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
proposal: rename disable_nojekyll to enable_jekyll #130
Comments
Thank you for suggesting this, and I am sorry for confusing you. Document Changing
I totally agree with your changes of the documentation. (My notes old docs) Could you open your pull request to update the documentation? @Cito About Renaming
Maybe, it is friendly and understandable for users to add the CC: @nicolas-van @dhimmel |
Thank you for the quick response. Sure, the |
v3.5.0 has been released and v3 updated. Thanks. |
Thank you for providing this useful tool, I like it a lot.
But today I stumbled over a small issue that made me waste too much time finding the cause. The problem was that the deployment worked, but all the CSS files did not show up. It did not help that GitHub had outages today which affected GitHub actions and GitHub pages and made me believe this could have caused it. Then it took me much time to find that the problem were not CSS files by themselves, but the fact that they were located in a directory starting with an underscore. All such files and directories did not seem to be visible. That was strange because they were visible in other projects. Finally, I found that this happens when Jekyll is activated. And then I saw my mistake: I had set
disable_nojekyll: true
believing that would create the.nojekyll
file and disable Jekyll, while the opposite was the case. The double negative somehow was too much for my little brain today.So my proposal is to rename the
disable_nojekyll
option toenable_jekyll
, avoiding the double negative that can cause confusion.Also, the documentation is not very clear. It says:
It is unclear here whether "this behavior" refers to the fact that it adds the file only to the master and gh-pages branches or to the fact that the action creates the file at all.
My suggestion is to clarify the documentation a bit:
The text was updated successfully, but these errors were encountered: