The content of this docs repo is taken from the docs content of the website repo and is up to date as of forgejo/website@ffa9478411.
I have rewritten the history of the repo so that:
- Each version of the docs branches off the
next branch instead of duplicating files.
This gives us a much better history for each file and better blame output.
- Merge commits are greatly reduced.
At present the docs files live in the root of the repo, with images in the _images subdirectory. This was easiest for pulling the content in as submodules on the website repo.
However, I might change this to put the content in a docs subdirectory, so that we can put a readme, contributing guide, etc in the root without them becoming part of the website.
The intended strategy for contributions to the docs is as follows:
- PRs should be sent against either the
next branch or a version branch as appropriate
- When merging PRs, merge commits should be avoided where possible, by fast-forwarding and squashing where appropriate. Single commits should always be fast-forwarded.
- Changes can be back- or front-ported by cherry-picking.
For larger sets of changes, feature branches can be created and can then be merged into multiple docs branches. However this will require the feature branches to be branched from the common ancestor of all the branches into which it is to be merged, which may sometimes result in many conflicts.
I would appreciate any feedback on all of the above.
The content of this docs repo is taken from the [docs content of the website repo](https://codeberg.org/forgejo/website/src/branch/main/src/content/docs) and is up to date as of https://codeberg.org/forgejo/website/commit/ffa9478411ac0a8348062c4b1ea93bc8e273ddb4.
I have rewritten the history of the repo so that:
- Each version of the docs branches off the `next` branch instead of duplicating files.
This gives us a much better history for each file and better `blame` output.
- Merge commits are greatly reduced.
At present the docs files live in the root of the repo, with images in the `_images` subdirectory. This was easiest for pulling the content in as submodules on the website repo.
However, I might change this to put the content in a `docs` subdirectory, so that we can put a readme, contributing guide, etc in the root without them becoming part of the website.
The intended strategy for contributions to the docs is as follows:
- PRs should be sent against either the `next` branch or a version branch as appropriate
- When merging PRs, merge commits should be avoided where possible, by fast-forwarding and squashing where appropriate. Single commits should always be fast-forwarded.
- Changes can be back- or front-ported by cherry-picking.
For larger sets of changes, feature branches can be created and can then be merged into multiple docs branches. However this will require the feature branches to be branched from the common ancestor of all the branches into which it is to be merged, which may sometimes result in many conflicts.
I would appreciate any feedback on all of the above.