@wjt and it's also possible to update only a subdirectory, which I plan to use to host multiple unrelated things in the same host. It wasn't the main reason for me to choose #GitPages but it's one more small detail I can take advantage of.

The features that convinced me to use #GitPages are that I can throw a tarball with the contents of a website at it, without needing an actual Git repository with the contents; and that `curl` can be easily coerced into being a client wherever `git-pages-cli` may not be available.

This is perfect for cases in which the repository contains the source for the website that needs to be transformed before publishing, because it avoids needing to artificially store the “rendered” content in a branch of the Git repository, which wastes disk space.

Today I built and deployed #GitPages on one of my #OpenBSD boxes for personal usage... and it works beautifully behind relayd.

Thanks to @whitequark for such a neat piece of software 

#GitPages now has a _redirects file linter that warns you if your redirect accidentally ends up "dead" (never triggered because you have a file with the same name)

#GitPages now supports incremental site updates when uploading via the CLI!

pictured are logs for two individual uploads:
1a. PUT probe (says blobs are missing)
1b. PUT upload (uploads all the blobs)
2. PUT probe (says all the blobs are already there)

#GitPages now implements an audit system that allows on-line, background processing of uploaded content to e.g. scan it for viruses, phishing, and other abusive material

I consider this table stakes for any service with open registration, so now I can finally say that git-pages is _almost_ done (it needs a GC and a few minor fixes to other functions)

https://codeberg.org/git-pages/git-pages/issues/82#issuecomment-8707941

#GitPages now supports atomic partial updates using the PATCH method: give it a subdirectory and it will update its contents without touching anything else

you can use it to e.g. upload previews of built documentation without having to maintain giant git checkouts with stale files for thousands of pull requests. and it's efficient, too!

see https://codeberg.org/whitequark/whitequark.codeberg.page/src/commit/fc1c39ab1bfdd934934551de5ed9b7792f9d1d22/.forgejo/workflows/publish.yaml for an example workflow

https://whitequark.codeberg.page/
https://whitequark.codeberg.page/preview/pull/1/

check out how quickly #GitPages (and #Grebedoc) can check out a giant git repository without any changes!

if supported by the server, it retrieves only a single tree from git (no other branches, no tags, no history, no file contents), backfills it from the existing site contents, and then pulls in any missing files from the git server on-demand

this lets you publish very large repositories as static sites without straining network and compute (for compression, etc) resources!

Thinking about revamping my personal webpage and blog space (even if my blog has been especially quite lately). Currently written in #RMarkdown anyone have an recommendations on different templates? #GitHub #GitPages #RMarkdown style templates would be ideal. https://swampthingecology.org/
Paul Julian II, PhD