Reimagining the Forge: Core Features Users Really Need

The conversation sparked by What would you want from a forge? on Lobsters surfaces a recurring frustration: most hosted version‑control front‑ends have converged on a narrow set of interaction patterns, while many developers crave richer, more resilient collaboration primitives. Below I distill the most compelling proposals that emerged, explain why they matter, and sketch how they could be realized.

---

1. Immutable, VCS‑anchored Code‑Review Histories

The problem

Current giants such as GitHub or GitLab store review comments in a separate database. When a branch is rebased, force‑pushed, or the repository is migrated, those discussions can become detached from the code they refer to, effectively losing context. The community view expressed by a comment on the thread is that this separation is a risk: the historical record of why a line of code exists should travel with the commit itself.

A concrete proposal

• Store comments as signed objects in the repository. Each comment would be a lightweight blob whose hash is derived from the target commit hash, file path, and line number. By signing the blob with the reviewer’s GPG key, the system guarantees authenticity.
• Expose a thin web UI that reads these objects directly from the Git object store, rendering them alongside the diff. Since the data lives in the same storage layer as the code, any clone of the repo automatically contains the full review history.
• Leverage existing tooling: Fossil already demonstrates a similar approach for tickets; extending it to handle per‑line review comments would close the gap.

Implications

• Longevity – reviewers’ insights survive repository forks and archival snapshots.
• Transparency – anyone cloning the repo can audit the decision‑making process without needing privileged API access.
• Portability – moving the repository to a new forge does not require a data migration for reviews.

---

2. Decentralized, Real‑Time Patch Collaboration via XMPP

The problem

The “pull request” model dominates, yet many teams still rely on email‑based workflows (Gerrit, mailing‑list patches). Email is asynchronous and lacks the immediacy of modern chat, while existing chat‑based solutions rarely integrate with the VCS in a first‑class way.

A concrete proposal

• Use XMPP MUC (multi‑user chat) rooms as live patch workspaces. When a developer pushes a patch set, a temporary MUC is created; participants can discuss, react, and attach files directly in the room.
• Define a set of XEPs (e.g., xep-0313 for message archive, xep-0280 for pub/sub) to persist the discussion and to broadcast state changes (e.g., “patch marked ready”).
• Bridge the room to CI: a bot monitors the MUC, extracts the patch, runs tests, and posts results back into the chat. When the CI passes and the patch is approved, the bot can automatically merge it.
• Client‑agnostic: any XMPP client—desktop, mobile, or web—can participate, preserving the decentralized ethos.

Implications

• Real‑time feedback reduces the latency between suggestion and implementation.
• Federation means organizations can host their own XMPP servers while still interoperating with external contributors.
• Auditability – the XMPP archive (MAM) provides a searchable, tamper‑evident log of the discussion, which can be linked back to the commit hash.

---

3. Built‑in Merge Queue with “Ready‑to‑Integrate” Flags

The problem

Large projects suffer from a chaotic main branch: contributors push directly, CI flaps, and merges happen out of order, leading to flaky builds and wasted resources. Existing solutions (GitHub’s “merge queue”, Gerrit’s “submit queue”) are add‑ons rather than intrinsic parts of the repository model.

A concrete proposal

• Introduce a ready label that contributors can attach to a commit (e.g., via a signed tag ready/<sha>). The label is part of the repository’s metadata.
• A daemon watches the repository for new ready tags, schedules CI for each, and, once a job passes, atomically fast‑forwards the protected main branch to that commit.
• Queue ordering can be deterministic (e.g., based on timestamp) or policy‑driven (e.g., prioritize patches that touch critical modules).
• Rollback safety – because each merge is a single, signed commit, reverting to a previous known‑good hash is trivial.

Implications

• Predictable CI usage – the queue ensures only one CI job per pending change runs at a time, avoiding redundant builds.
• Clear ownership – the ready flag signals intent without granting write permission to the protected branch.
• Extensibility – other tools (e.g., bots that auto‑label patches after passing a static analysis step) can participate in the queue without human intervention.

---

4. Heterogeneous CI as a First‑Class Repository Feature

The problem

Modern CI pipelines are often monolithic, cloud‑hosted services that assume a homogeneous build environment. This limits testing on niche platforms (e.g., embedded ARM, legacy macOS) and forces teams to maintain parallel CI configurations.

A concrete proposal

• Treat CI tasks as objects stored alongside the code. A ci.yaml file in the repo declares a matrix of platforms, each referencing a Docker image or VM definition.
• Runtime isolation: a lightweight executor (similar to nix run or podman) pulls the appropriate image, runs the defined steps, and records the result as a signed artifact whose hash incorporates the platform identifier.
• Discovery via the VCS: any clone can run git ci run --platform windows to reproduce the exact CI environment locally, facilitating debugging.
• Federated runners: organizations can expose their own runner pools (e.g., a Windows build farm) that subscribe to the repository’s CI queue via a pub/sub protocol.

Implications

• Transparency – the exact environment that produced a build artifact is versioned and reproducible.
• Flexibility – adding a new platform is a matter of committing a new entry to ci.yaml, not negotiating with a third‑party service.
• Cost control – teams can self‑host runners for expensive platforms while delegating cheap Linux builds to a public service.

---

5. Rethinking Presentation of Repository Objects

The problem

Most forges display tags, commits, and trees in a uniform, almost decorative way. Users rarely get to interact with the underlying graph beyond scrolling through a linear history.

A concrete proposal

• Graph‑centric UI: expose a navigable DAG where each node is a commit and edges represent parent relationships. Users can toggle between linear and branch views, similar to how Git’s git log --graph works but in the browser.
• Tag heatmaps: visual cues (color intensity) indicate how many branches reference a tag, helping users spot “orphaned” releases.
• Blob preview pane: clicking a file shows a diff‑aware viewer that can render any MIME type (e.g., images, PDFs) directly, reducing the need to download raw blobs.
• Search‑driven navigation: integrate full‑text search over commit messages, file contents, and review comments, allowing developers to jump to the exact point of interest.

Implications

• Better mental model – developers can see the true shape of the project’s evolution, not just a flattened timeline.
• Reduced friction – quick previews of binary assets prevent unnecessary clone operations.
• Enhanced discoverability – powerful search surfaces historical decisions that might otherwise be buried.

---

Counter‑Perspectives and Trade‑offs

While the proposals above promise a more resilient and expressive forge experience, they also introduce complexity:

• Storage overhead – embedding review comments in the VCS inflates repository size, especially for large projects with extensive discussions. Mitigation could involve compression and pruning of stale comments.
• Operational burden – running XMPP servers and custom CI executors requires expertise that many small teams lack. Offering hosted, managed instances could lower the entry barrier.
• User adoption – developers accustomed to the simplicity of a single pull‑request UI may resist a multi‑tool workflow that mixes chat, tags, and queues. Incremental rollout (e.g., opt‑in ready tags) can ease the transition.
• Security considerations – signing objects and authenticating XMPP participants adds attack surface; robust key‑management policies are essential.

---

Conclusion

The discussion on Lobsters reveals a clear desire for forges that treat code, discussion, and automation as a single, immutable artifact. By anchoring review comments in the repository, enabling real‑time, federated patch collaboration, formalizing a merge‑queue mechanism, and making heterogeneous CI a native part of the VCS, we can move beyond the “pull request” monolith toward a more democratic, reproducible, and transparent development ecosystem. Implementing these ideas will not be trivial, but the payoff—a repository that truly records what changed, why it changed, and how it was validated—aligns closely with the core values of version control: history, collaboration, and trust.