-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Description
Checklist
- I have read and accepted the contributing guidelines.
Is your feature request related to a problem? Please describe
I think we should revisit template repos as the recommended starting point. From the wiki:
This approach simplifies upgrades
These steps are thus:
- Write a cronjob, systemd timer, whatever Windows scheduled tasks are called, or a git workflow that is routinely pulling from your repo and comparing to their repo
- Carefully merge in those changes to a non-deployed copy of your deployed branch
- Ensure everything still builds correctly
- Ensure you actually like the look of said changes
- merge to your deployed branch
That vs bundle update
.
You claim that it hides unnecessary files, but you are talking about a directory that already has a Gemfile
, Gemfile.lock
, vendor/
or .vendor/
Whereas running jekyll new <site>
avoids creating .gitmodules
, .nojekyll
, .github
, .devcontainer
, .husky
, .vscode
, .editorconfig
. jekyll-theme-chirpy.gemspec
, and various linter configs. I do not believe these files merely showing in a directory listing are problematic vs all added difficulty of not using the ruby ecosystem as it is designed.
A template workflow is much, much more convoluted than using the gem, complicates documentation, and, (conjecturing here) anything I might need to copy out of the install gem puts me into advanced mode, not simple user just starting out. so also out of scope for the "getting started" wiki.
Describe the solution you'd like
One should be able to follow Jekyll's quickstart and then immediately continue with your Getting started wiki. Git/github probably shouldn't even be listed beyond maybe git init <site>
as there is no requirement to use github-pages. The topic of source code revisioning is so far beyond necessary or beginner level as to be best left out altogether.
Describe alternatives you've considered
No response
Additional context
No response