The plan says what g1t is for without measuring it against other products
1 file+3−190/1 viewed
| 11 | 11 | ||
| 12 | 12 | ## The point | |
| 13 | 13 | ||
| 14 | − | **GitHub is where people keep code. g1t is where a team of agents ships it.** | |
| 14 | + | **g1t is where a team of agents ships code, with the people they work for.** | |
| 15 | 15 | ||
| 16 | − | Hosting git is table stakes, and g1t does it the way GitHub does: issues, | |
| 16 | + | Hosting git is table stakes, and g1t does it the familiar way: issues, | |
| 17 | 17 | branches, pull requests, review, protected branches, people working by hand. | |
| 18 | 18 | None of that is the selling point. The selling point is the layer above it, | |
| 19 | 19 | which no forge has: **you hand g1t an outcome, and a fleet of agents converges | |
| 25 | 25 | 1. **Outcomes, not pull requests.** The unit people work in is "make onboarding | |
| 26 | 26 | work offline", not branch #4012. A brief becomes a plan of issues with | |
| 27 | 27 | dependencies; agents take them as they unblock; people steer the outcome | |
| 28 | − | and see it converge. GitHub, Origin and Entire all stop at the pull request. | |
| 28 | + | and see it converge, rather than stopping at the pull request. | |
| 29 | 29 | 2. **Agents that work as a team.** Agents know what the others are doing, file | |
| 30 | 30 | what they find instead of widening their change, ask and answer each other | |
| 31 | 31 | through the forge, and defer to people. Many agents on one codebase without | |
| 33 | 33 | 3. **`main` that only ever moves forward.** Every change lands through checks | |
| 34 | 34 | in the combination it will live in (the merge queue), failures go back to the | |
| 35 | 35 | agent that wrote them, and any line can answer "why is this here?" | |
| 36 | − | ||
| 37 | − | ### Against the others | |
| 38 | − | ||
| 39 | − | | | GitHub | Cursor Origin | Entire | g1t | | |
| 40 | − | | --- | --- | --- | --- | --- | | |
| 41 | − | | Core idea | Code hosting with Copilot bolted on | A forge for Cursor's cloud agents | Store every agent session with the code | Agents converge an outcome onto `main` | | |
| 42 | − | | Unit of work | Pull request | Pull request, stacked | Commit plus session | Outcome → plan → issues → pull requests | | |
| 43 | − | | Agent context | In the Copilot app | In Cursor | In the repo, per commit | Per commit, plus why-blame on any line and what agents told each other | | |
| 44 | − | | Many agents at once | Compare outputs by hand | Agents can review agents | Not the focus | Plan with dependencies, overlap awareness, coordination tools, queue | | |
| 45 | − | | Landing | Merge queue (paid) | Stacks | Not the focus | Speculative queue testing combinations; failures return to their agent | | |
| 46 | − | | Which agents | Copilot, some others | Cursor's | Any (CLI) | Hosted agents plus any MCP client | | |
| 47 | − | ||
| 48 | − | Entire's insight, that the session belongs with the code, is one g1t shares | |
| 49 | − | and already ships (sessions, why-blame). Origin's, that agents should live in | |
| 50 | − | the forge, too. Neither coordinates a team of agents towards an outcome; that | |
| 51 | − | is the gap g1t is built for. | |
| 52 | 36 | ||
| 53 | 37 | ## Product model | |
| 54 | 38 |