git

Overview ¶

browse.go — Hanzo Git's JSON read/browse surface: the machine-readable twin of the server-rendered UI (ui.go). The console repo-browser (hanzoai/console components/products/git) consumes THESE endpoints; ui.go serves the same data as HTML for a plain browser. Both read through the ONE Repository model (repository.go), so the two surfaces can never drift and neither knows which version-control system is underneath.

Routes (JSON, org-scoped — distinct trailing segments that never shadow the :org/:repo smart-HTTP protocol routes):

GET /v1/git/repos/:name/refs                 → { branches, tags, default }
GET /v1/git/repos/:name/tree?ref&path        → { entries: [ {name,path,type,size,mode} ] }
GET /v1/git/repos/:name/blob?ref&path        → { path,size,encoding,content,binary,truncated }
GET /v1/git/repos/:name/commits?ref&path&limit → { commits: [ {sha,shortSha,message,author*,date} ] }
GET /v1/git/repos/:name/readme?ref           → { path, content, encoding }

ref + path ride as ?ref=&path= QUERY params (the UI's own convention), so a slashed branch (feature/x) and a nested path are always unambiguous. Isolation is identical to the rest of git: the org is the gateway-minted, IAM-validated X-Org-Id (org(c)); a repo outside the caller's org is simply not found.

Package git mounts the Hanzo Cloud /v1/git surface: S3-backed Git hosting native in the unified cloud binary — Hanzo Git, the internal git host foundation agents push code into.

A repo is the Git LAYER (source code, buildable/deployable) that lives UNDER an IAM project. It is NOT the IAM project itself: `project` is org-scoping CONTEXT (org → project → env); a repo is scoped BY that context. Every repo belongs to exactly one org (the gateway-minted X-Org-Id, HIP-0026) and an optional project sub-scope (X-Project-Id), enforced on every query, so one org can never read, clone, push to, or delete another's repos.

Surface:

POST   /v1/git/repos            create a bare repo            -> repoView (201)
GET    /v1/git/repos            list the org's repos       -> {data:[repoView]}
GET    /v1/git/repos/:name      repo detail (branches, HEAD)  -> repoView
DELETE /v1/git/repos/:name      delete + purge storage        -> 204
GET    /v1/git/usage            per-repo + total bytes        -> usageView

Smart-HTTP git protocol (so `git clone` / `git push` work natively):

GET  /v1/git/:org/:repo/info/refs?service=git-upload-pack|git-receive-pack
POST /v1/git/:org/:repo/git-upload-pack     (clone/fetch)
POST /v1/git/:org/:repo/git-receive-pack    (push)

Storage is bare git repos on a real filesystem (osfs) rooted under {DataDir}/git; go-git initializes + reads them, while the heavy clone/push/ mirror paths stream through the `git` CLI (gitexec.go) so multi-GB packs stay bounded in memory. See storage.go for the hanzoai/vfs (S3) storage seam.

Billing: every repo tracks sizeBytes, re-measured on create and after each push. /v1/git/usage exposes per-repo + total bytes per org, and each measurement emits a "git.usage" log line a metering consumer can bill on.

gitbackend.go — git as ONE implementation of Repository (repository.go).

This is the only file on the read path that knows go-git exists. Everything go-git-shaped stops here: *gogit.Repository, *object.Commit, plumbing.Hash, filemode.FileMode. Readers above it see refs, revisions, trees and bytes.

The logic is lifted verbatim from the helpers this replaces (openGit, resolveRef, treeEntriesJSON, readmeAt, treeTextFiles) so the observable behaviour — ref-resolution fallbacks, dirs-before-files ordering, the binary check, the README candidate list — is unchanged. The one deliberate difference is that failures now come back as the model's sentinel errors instead of raw go-git errors, so a handler can tell "no such ref" from "this repository is broken" rather than reporting both as 404.

repository.go — the value at the centre of /v1/git: a Repository is a named, versioned content tree. Refs name revisions; a revision has a tree of paths; a path holds bytes. That is the whole model, and it is what every reader actually needs — the JSON browse surface (browse.go), the HTML twin (ui.go), and the code-intelligence feeder that hands content to /v1/code (index_on_push.go).

Git is ONE implementation of this model, not the model itself. It is a very good one — a content-addressed Merkle DAG, so the store falls out for free — but "revision" is a commit sha only because git says so; another backend may number its revisions or name them. Nothing above this file may assume otherwise, which is why Revision is an opaque string and why no go-git type (*gogit.Repository, *object.Commit, plumbing.Hash) appears in this file or in any signature a consumer touches. Those types live behind the backend, in gitbackend.go.

The protocol adapters are deliberately NOT expressed here. smart_http.go, ssh.go, pack.go and gitexec.go speak the git wire protocol and stream packs through the git CLI; they are git-by-definition and each sits at its own slot. Adding hg or svn means adding a backend beside gitbackend.go plus its own adapter — it does not mean touching a single reader.

ui.go — Hanzo Git's web UI: the browser surface of the embedded, IAM-native git host. Server-rendered HTML in the ONE cloud binary (no separate app, no stock git-host image), reading the SAME org-scoped store + go-git object storage the API/protocol handlers use. This is what lets git.hanzo.ai retire the standalone git web app: repo list, repo home, tree browse, file view, commit log — all native.

Isolation is identical to the rest of git: every page is scoped to the gateway-minted, IAM-VALIDATED X-Org-Id (org(c)); the :org path segment MUST equal the caller's own org, so the UI can never browse another tenant's repos. html/template auto-escaping is the XSS boundary — repo names, paths, and file contents are all rendered through it, never concatenated into HTML.

Routes (browser, distinct from the /v1/git API + smart-HTTP protocol):

GET /git                         the caller's org repo list (home)
GET /git/:org/:repo              repo home: branches, HEAD, root tree, clone
GET /git/:org/:repo/tree/*?ref=  browse a subtree
GET /git/:org/:repo/blob/*?ref=  view a file
GET /git/:org/:repo/commits?ref= commit log

ui_templates.go — the Hanzo Git UI's view layer: data shapes, the render() helper, and the html/template set (chrome + pages). Kept apart from ui.go so the handlers read as flow and the markup lives in one place. All dynamic values pass through html/template auto-escaping — the XSS boundary.