PUBLICATION CHECKLIST — NOT YET A LIVE POLICY. [[REVIEW_REQUIRED]] Confirm the operator identity, contact channels, hosting and retention practices, legal bases, actual product behaviour and applicable Dutch/EU law. Have the document reviewed and remove this notice only when verified. Publication requires an explicit administrator action.

Git Hosting and Repository Policy

What ArchForge hosts

ArchForge supports public and private Git repositories, Git Smart HTTP, source downloads, branches, tags, forks, pull requests and repository-associated content. The Git protocol records commit author names and email addresses supplied by the committer, which are not verified proof of an ArchForge account or an endorsement.

Public and private visibility

Public repositories can be browsed and cloned without signing in. This includes public Git metadata and historical file content; Git history can contain older material that is not visible at the newest commit. Private repositories require server permissions, but are not end-to-end encrypted. Authorized maintainers and collaborators may download entire histories. Never place credentials or sensitive third-party data in Git even temporarily.

Permissions and security

Write access requires a valid authenticated identity and appropriate token permission or supported Git transport. Protected branches and repository rules apply regardless of the interface used. Force pushes and history rewrites can invalidate links and do not delete existing third-party clones. The desktop application cannot bypass server permissions. Public clones do not grant push rights.

Storage, backups and deletion

Actual storage quotas, maximum file sizes, Git objects and backup policies are controlled by the live server configuration: {{VERIFIED_GIT_QUOTAS_AND_BACKUPS}}. Repository deletion or account closure may be subject to confirmation, legal preservation and backup rotation. Git forks, third-party mirrors and clones remain separate. Any promised recovery period must be documented before publication.

Software licenses and contributor obligations

An explicit repository license determines what recipients may do with code, subject to law. No license does not mean public-domain code. Contributors should confirm they have authority to submit patches and that their changes comply with project rules, attribution obligations and third-party licenses.

Third-party services and webhooks

A repository maintainer who enables a webhook or a Discord integration selects an external recipient of event data. Only authorized repository users should configure these integrations, which may expose repository names, commit metadata and event details to the chosen recipient.

Changes and version history

This policy applies from its stated effective date once published. Material changes are dated and versioned. Earlier versions remain available to administrators for audit, and any notice or renewed agreement required by applicable law is handled separately. Questions and legally valid notices may be sent using the contact details in the Legal Notice.