Migrate information from the wiki to GitGitGadget's home page #21
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…the Git mailing list
Signed-off-by: Johannes Schindelin <[email protected]>
This merges the pages from the wiki, they will be subsequently transformed into `.html` pages. The reason for the migration away from the wiki is that the wiki can only be edited by people with `push` permissions, to combat spam. But GitGitGadget's home page can be edited via PRs. Signed-off-by: Johannes Schindelin <[email protected]>
This is not needed on GitGitGadget's home page, which already has an `index.html`. Signed-off-by: Johannes Schindelin <[email protected]>
These filenames will be used in the URLs. Therefore, long names and special characters are undesirable. Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Let's use 2-space indents everywhere in this repository. This commit is best viewed with `git show -w`. Signed-off-by: Johannes Schindelin <[email protected]>
This imitates the Grunt-based setup of git-for-windows.github.io. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
add-information-from-the-wiki
branch
from
77429d3 to
dda7067
Compare
This will make it more convenient to update the site: Simply modifying the `.md` files will be enough, and the PR build will do the rest. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
add-information-from-the-wiki
branch
from
dda7067 to
e395bbf
Compare
dscho
changed the title
|
A couple of (potential) follow-ups that come to my mind are:
|
This was referenced Mar 5, 2025
Merged
dscho
added a commit
that referenced
this pull request
Mar 8, 2025
Rather than trying to continue running something home-grown, let's switch to a proper static site generator. This partially addresses some concerns I [raised after integrating the wiki pages](#21 (comment)) and the problems we ran into when [the workflow to update the HTML pages failed in a PR by a contributor](#22 (comment)): While it still does not offer convenient before/after views, it at least allows to preview the changes in a fork, just like this here PR can be previewed at https://dscho.github.io/gitgitgadget.github.io/ So why even bother with a powerful site generator like Hugo for something as small as GitGitGadget's home page? Well, here are a couple of reasons: - As you can see https://dscho.github.io/gitgitgadget.github.io/architecture, it re-adds the syntax highlighting in code blocks that were lost in the transition away from the wiki. - It will make auto-generating a navigation bar (or a central index page) much easier. - It will make it easier to maintain a unified look-and-feel, e.g. when adding something like an "Edit on GitHub" button. - It should make it somewhat easier to make the site [responsive](#19) because of a much more standard way to build the site. - The migration of the wiki pages was meant as a blueprint I could follow in Git for Windows, where I want to stop wasting my time battling spam and vandalism, and any subsequent work over here that can help with that can increase the synergy between both projects.
dscho
added a commit
to dscho/gitgitgadget
that referenced
this pull request
Mar 14, 2025
Since the wiki was locked down for external contributors (to prevent spam and vandalism), it was not really a good place for the information. As of gitgitgadget/gitgitgadget.github.io#21 it moved to GitGitGadget's home page. Let's stop referring to the wiki for that reason, and refer to the new location instead. Signed-off-by: Johannes Schindelin <[email protected]>
↪gitgitgadget/gitgitgadget#1852
I guess another idea would be to make it a "site map" or "site index", similar to what I did over in git-for-windows/git-for-windows.github.io@10c86c2.
Since moving to Hugo in #23, that is no longer relevant.
These would still be "nices-to-have". |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The idea of having a wiki sounded better when I added information there than years later, when I needed to limit write permissions to combat spam. That kind of defeats the purpose of a wiki, where it should be as easy as possible to edit the information for anyone who sees a mistake (or something that would benefit from an improvement).
One example where this really irks is gitgitgadget/gitgitgadget#1843: A good suggestion how to improve the documentation how to reply to comments on the Git mailing list, and the person who proposed a change could not make that change themselves.
So let's import the information from the wiki pages and put them on GitGitGadget's site instead. The next step after merging this PR will be to edit the wiki pages themselves to redirect to https://gitgitgadget.github.io/architecture and https://gitgitgadget.github.io/reply-to-this instead.