If this repo is forked, push the rendered pages to the forked repo, not to the original.
Also make sure the rendered gitea link points to the forked repo.
If this repo is forked, push the rendered pages to the forked repo, not to the original.
Also make sure the rendered gitea link points to the forked repo.
This could help if many people are working on documentation at the same time (a.k.a. documentathon). In order not to step on each other's feet with git pushes and maybe/likely zensical redering errors, people can create their own fork in their own name space. ([Fork] button in top right corner)
For example if the repo is forked to user/controls-docs, then the private copy of the rendered page should appear as https://user.controls-docs.pages.psi.ch. (I recommend to change the repo name for the fork and not to keep the name "gitea-pages" because then it would become the main web page of the user at URL https://user.pages.psi.ch, just like it is the main web page of this organization, and may conflict with a gitea page the user already has.)
Once everything renders correctly, users can create a merge request to get their contribution back into the original (this) repo.
For the maintainer of this repo, I suggest to use merge option "rebase and feed-forward" (to keep each commit visible in the history) or "squash commit" (to collapse all commits into one, i.e. avoid dozens of render-fail-try-again-commits showing in the history) if available. As long as not two contributors have edited the same line in the same file, it should merge without conflict.
This could help if many people are working on documentation at the same time (a.k.a. documentathon). In order not to step on each other's feet with git pushes and maybe/likely zensical redering errors, people can create their own fork in their own name space. ([Fork] button in top right corner)
For example if the repo is forked to **_user_/controls-docs**, then the private copy of the rendered page should appear as **https://_user_.controls-docs.pages.psi.ch**. (I recommend to change the repo name for the fork and not to keep the name "gitea-pages" because then it would become the main web page of the user at URL **https://_user_.pages.psi.ch**, just like it is the main web page of this organization, and may conflict with a gitea page the user already has.)
Once everything renders correctly, users can create a merge request to get their contribution back into the original (this) repo.
For the maintainer of this repo, I suggest to use merge option "rebase and feed-forward" (to keep each commit visible in the history) or "squash commit" (to collapse all commits into one, i.e. avoid dozens of render-fail-try-again-commits showing in the history) if available. As long as not two contributors have edited the same line in the same file, it should merge without conflict.
If this repo is forked, push the rendered pages to the forked repo,
not to the original.
Also make sure the rendered gitea link points to the forked repo.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
If this repo is forked, push the rendered pages to the forked repo, not to the original.
Also make sure the rendered gitea link points to the forked repo.
This could help if many people are working on documentation at the same time (a.k.a. documentathon). In order not to step on each other's feet with git pushes and maybe/likely zensical redering errors, people can create their own fork in their own name space. ([Fork] button in top right corner)
For example if the repo is forked to user/controls-docs, then the private copy of the rendered page should appear as https://user.controls-docs.pages.psi.ch. (I recommend to change the repo name for the fork and not to keep the name "gitea-pages" because then it would become the main web page of the user at URL https://user.pages.psi.ch, just like it is the main web page of this organization, and may conflict with a gitea page the user already has.)
Once everything renders correctly, users can create a merge request to get their contribution back into the original (this) repo.
For the maintainer of this repo, I suggest to use merge option "rebase and feed-forward" (to keep each commit visible in the history) or "squash commit" (to collapse all commits into one, i.e. avoid dozens of render-fail-try-again-commits showing in the history) if available. As long as not two contributors have edited the same line in the same file, it should merge without conflict.
531b3ccc83toee77a28819