IdeaWell

Project ideas from Hacker News discussions.

Maiao: Gerrit-style code review workflow for GitHub, GitLab, Gitea, others

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Theme 1 – Stacked PRs / one‑commit‑per‑PR workflow
Many commenters discuss the practice of treating each commit as an independent, reviewable unit (often called “stacked diffs”).
- “When you work this way, each commit is expected to be able to land independently.” – steveklabnik
- “1 commit == 1 reviewable unit == 1 PR == 1 CL == 1 feature == 1 fix is a perfectly reasonable way of working.” – jsphweid
- Critics call it “crazy town” and question the need for multiple PRs: “sounds like crazy town.” – NamlchakKhandro

Theme 2 – Gerrit vs. GitHub UI/UX preferences
Several participants express nostalgia for Gerrit’s review interface and wish GitHub offered a similar experience.
- “As someone who much prefers Gerrit's UI/UX over GitHub's UI, I was disappointed that this wasn't replicating the UI for GH reviews.” – jasonlotito
- “Gerrit. Now that's a name I've not heard in a long time.” – martythemaniak

Theme 3 – Workflow practicality and team‑size considerations
The conversation turns to when stacked PRs make sense versus traditional PRs, noting trade‑offs like force‑pushing, squashing, and team scale.
- “On large teams I think the 'cherry pick' workflow (Gerrit style) beats the 'pull request' workflow … On smaller teams it's the other way around… around 10‑20 people actively committing that the cherry pick workflow comes out ahead.” – verall
- “Isn’t the purity you’re describing a bit of a dodge in that you wind up force pushing amended commits when you find you forgot something?” – tclancy
- Discussions also cover squashing on merge vs. preserving history: “it lets you maintain version history when working, then most workflows auto squash on merge.” – cobalt

🚀 Project Ideas

StackedPR

Summary

  • Provides a Gerrit‑style stacked diff workflow on GitHub: each commit in a feature branch is automatically presented as its own PR, with dependency tracking and easy rebasing.
  • Core value: developers get reviewable, independently testable units without leaving GitHub, reducing “crazy town” confusion around multi‑commit PRs.

Details

Key Value
Target Audience Teams using GitHub who prefer one‑commit‑per‑PR or stacked diffs (open source, mid‑size to large orgs)
Core Feature Auto‑creation of PRs per commit, visual stack UI, rebase‑on‑parent, auto‑squash on merge, status checks per PR
Tech Stack Node.js (Probot) for GitHub App, React for UI, PostgreSQL for metadata, GitHub Actions for CI
Difficulty Medium
Monetization Revenue-ready: $9 per active user per month (tiered team plans)

Notes

  • HN commenters lamented missing Gerrit UI and wanted stacked PRs on GH (jasonlotito, steveklabnik). This directly addresses that wish.
  • Enables discussion on review efficiency and can be adopted incrementally; practical utility for CI/CD pipelines needing per‑commit deployability.

GerritHub UI

Summary

  • A browser extension that overlays Gerrit’s review‑centric UI onto GitHub PR pages, showing change‑centric diffs, inline commenting, and a unified change list.
  • Core value: gives Gerrit aficionados the familiar UX they miss while keeping GitHub as the host, satisfying the “wish someone would create such a thing for those of us forced to leave Gerrit behind” (jasonlotito).

Details

Key Value
Target Audience Developers who miss Gerrit’s UI/UX and work on GitHub (individual contributors, teams transitioning from Gerrit)
Core Feature Change‑centric view, side‑by‑side diff with comment handling, change‑list dashboard, email‑style notifications
Tech Stack TypeScript, WebExtension API (Chrome/Firefox), React, uses GitHub REST/GraphQL API
Difficulty Low
Monetization Hobby

Notes

  • Directly addresses the comment from jasonlotito about missing Gerrit UI and the desire for a replica.
  • Low barrier to entry; can spark discussion about UI preferences and be useful for teams evaluating Gerrit vs GitHub.

Commit2PR CLI

Summary

  • Command‑line tool that transforms a local branch with multiple commits into a series of dependent GitHub PRs, each representing one commit, handling rebasing, dependency tracking, and CI gating.
  • Core value: lets teams adopt the “one commit == one reviewable unit” workflow without manual PR creation, reducing the “crazy town” feeling and enabling independent deployability (as noted by steveklabnik and jsphweid).

Details

Key Value
Target Audience Engineering teams practicing stacked diffs or wanting fine‑grained PR reviews (DevOps, platform engineers)
Core Feature Generates PR per commit, updates stack on amend, auto‑rebases child PRs, status checks per PR, integrates with GitHub Checks
Tech Stack Go (or Rust) for CLI, Octokit for GitHub API, SQLite for local state
Difficulty Medium
Monetization Revenue-ready: $5 per user per month (team licensing)

Notes

  • Addresses the confusion expressed by users like what, chrisweekly, and jsphweid about why multiple commits per PR are needed; offers a pragmatic solution.
  • Encourages discussion on review practices and can be integrated into existing CI pipelines for safer merges.

Read Later