mirror of
https://github.com/hanzoai/forge.git
synced 2026-10-30 15:00:39 +00:00
zeekayandHanzo Dev
1414fd6ce0
Our own documentation called the product Gitea. It is Hanzo Forge, so it now says so — README family, CONTRIBUTING, docs/, and the per-package READMEs. Three kinds of "Gitea" are not branding, and they stay: - MIT attribution: the copyright header template, the LICENSE, and the "white-label fork of Gitea" statement in each README. - Provenance: modules/git came from go-gitea/git, the Actions token design was proposed upstream in #24635, the base is 1.26.4 of go-gitea/gitea. - Addressing values: /data/gitea and /etc/gitea, the gitea-data PVC, the GITEA__ env prefix, X-Gitea-* headers. LLM.md's inventory of these is unchanged. Links that pointed at upstream infrastructure described a project this fork is not. Contributor issues, security reports and documentation now land here; the Crowdin sync, the GiteaBot backporter, the blog PR and the dl.gitea.com asset checks describe no lane this repo has, and the release section now records the one it does — tag, push to canonical, semver image, universe pin. Four references were dead as written, not merely upstream: - docs/setup.md is docs/build-setup.md - build/backport-locale.go does not exist - .github/workflows does not exist here; the workflows are .hanzo/workflows - the -X ldflags named code.gitea.io/gitea symbols, which this binary has none of, so the linker set nothing. The module path is github.com/hanzoai/git and cmd.PIDFile defaults to /run/gitd.pid. gitea help and gitea completion are gitd. gitea-runner is git-runner. The GitHub repo is hanzoai/forge now, so the clone and fork URLs point there. ghcr.io/hanzoai/git is untouched: a package is not renamed by a repo rename and the running deployment pins that image. The Go module path is untouched for the same reason — go.mod still declares github.com/hanzoai/git. Co-authored-by: Hanzo Dev <[email protected]>
1.8 KiB
1.8 KiB
Refactoring guidelines
This document covers expectations for refactoring work. For the general workflow see CONTRIBUTING.md.
Background
Hanzo Forge is a large, long-lived project. Over time the codebase has accumulated outdated mechanisms, mixed frameworks, and legacy code that can cause bugs or slow down new features. Refactoring keeps the codebase maintainable, but it needs to be done carefully so it improves things without introducing regressions.
Writing a refactoring PR
- Be forward-looking: address the root cause, not just the immediate symptom.
- Aim to reduce ambiguity and conflicts and to improve maintainability.
- Explain the rationale in the PR description: why the refactor is necessary, how it resolves the legacy problem, and its advantages and disadvantages.
- Keep the scope tight: preserve existing behavior where feasible and avoid bundling unrelated changes.
- Break large refactors into intermediate steps across multiple PRs so each one is easy to review.
- Include tests that verify the behavior stays correct.
- Prefer scheduling non-bugfix refactoring early in a milestone, so any issues surface well before a release.
- If there is disagreement about a refactor, escalate to the Technical Oversight Committee (TOC) for a decision.
Reviewing and merging
- Keep refactoring PRs short-lived (typically no more than 7 days) with quick review cycles, and merge them promptly so they do not block on unrelated work.
- A non-author core member may approve and merge a refactoring PR after 7 days if the TOC has raised no objection.
- Accept imperfect intermediate implementations as long as the final result improves the codebase.
- A temporary regression caused by a necessary refactor is acceptable if it is fixed promptly afterwards.