syntaqxRepositories can be forked into a workspace, and pull requests merge by merge commit, squash, rebase or fast-forward, with every repository setting for pull requests, commits, pushes and issues. Forks: a fork is an ordinary repository with parent_id (repos 0019; fork_of still means only a pull request's hidden working copy) and forked_from, which is never cleared. Forking (web Fork button and page, POST /repos/{owner}/{name}/forks, MCP repository.fork, g1t repo fork) copies the code (the default branch only unless asked) and description, nothing else; Actions (actions 0023, Settings → Actions → Run workflows) and Issues (work has_issues) start off in a fork and stay off once it is detached unless someone turns them on. Public repositories can always be forked, private ones only with Allow forking, and the fork stays private; an hourly sweep deletes (restorably) a private fork whose maker can no longer read its parent (identity can_read_repo). A fork counts at its full size toward its workspace's storage, and a free workspace's private cap is checked first. Artifacts forks in the source's namespace, or the code is copied when the workspace keeps its data in the EU. A fork cannot change its visibility; a parent going public or private detaches its forks (repo.detached), and a purged parent's forks move to its parent. Sync fork (POST merge-upstream, g1t repo sync) fast-forwards, merges line by line, or names the clashing files, under the fork's own rules. Pull requests from a fork's branch (head_repo, work 0041) are reviewed, checked and merged on the parent; their runs are untrusted (no secrets, read-only token) whoever opened them; a reader of the parent sees a private fork's pull request diff only through commits the parent already holds; forks list, detach and the new-pull-request head picker complete it. A token for chosen repositories can no longer create a repository by forking or creating one. Merging: repos land makes merge commits, squashes (author the pull request's, Co-authored-by for the others, Signed-off-by where required) and rebases with line-level three-way merges, refusing with the clashing files, and fast-forward lands the checked commit as before; limits are 1,000 files, 100 line merges and 250 rebased commits. Update branch merges or rebases (PUT update-branch, g1t pr update-branch --rebase), honouring expected_head. Work (0042) adds the settings: allowed methods and the default, default messages for merge and squash with custom templates ({title} {number} {body} {branch} {head_repo} {base} {author} {commits} {issues} {co_authors}), always suggest updating branches, allow auto-merge, delete head branches on merge, require sign-off on web commits, allow commit comments, auto-close issues; merge_choices tells the merge box what may be used and the default messages. Rules' allowed_merge_methods are enforced and linear history refuses merge commits. A behind pull request, a fork's included, now merges directly unless it must be up to date. Auto-merge per pull request (PUT/DELETE auto-merge, g1t pr merge --auto) merges as whoever turned it on, checked against their access now and then, and turns itself off with a note and a notification when it no longer can, or when someone else pushes. Closing keywords (Fixes #12, closes owner/repo#3) close every issue named; head branches are deleted and restored from the pull request. Commit comments (work 0043) on a commit or a line, with notifications and commit_comment.* events; a per-push branch and tag limit (repos 0020, max_ref_updates); Include Git LFS objects in archives is shown, off and marked coming soon. The site's settings, merge box (methods, messages, auto-merge, update, delete and restore branch), commit page comments, fork pages and sync bar; the API (fork, forks, sync, detach, actions permissions, merge options, update branch, auto-merge, head branch, commit comments), MCP and CLI; docs: forking guide, forks concept page, pull requests, managing repositories, rules, Actions, webhooks, limitations, MCP reference and llms.txt. Deploy migrations first: repos 0019 and 0020, work 0041 to 0043, actions 0023; then identity, repos, work, actions, security, events, the API and the site together. Not yet: the merge queue lands the combination it tested as it is, whatever method was asked; Actions reads its settings more often than it needs; rebase force-moves branches in the git store, to be confirmed live. Checked: cargo test --workspace (repos 333, contracts 309, api 202, work 184, identity 174, actions 111, security 89, rules 74, events 57, the CLI's 105 and 51, all others passing), wasm32 checks of repos, work, actions, api, identity, security, events and search, the site's typecheck, tests (926) and production build, the contracts' and mobile app's typechecks, and the docs build; the site's new pages rendered with fixtures.c82bd53History
README.md
g1t/detect
Says what a g1t.page build of the checkout would find, without building or deploying anything: the same rules g1t/deploy builds with.
steps:
- uses: actions/checkout@v5
- id: detect
uses: g1t/detect@v1
- if: steps.detect.outputs.kind == 'none'
run: echo "::error::Nothing here would be served."
- if: steps.detect.outputs.framework == 'hugo'
run: echo "A Hugo site, served from ${{ steps.detect.outputs.output-dir }}"
- if: steps.detect.outputs.install != ''
run: ${{ steps.detect.outputs.install }}yaml
Inputs
| Input | Default | |
|---|---|---|
root-dir | The checkout | Where the project is in the checkout. |
build-command | None | A build command of your own, as g1t/deploy takes it. |
output-dir | None | An output folder of your own, as g1t/deploy takes it. |
build-as | auto | What it is built as: auto, static, workers or docker (Container), as g1t/deploy takes it. |
dockerfile | None | A Dockerfile's path of your own, as g1t/deploy takes it. |
Outputs
| Output | |
|---|---|
kind | workers (a wrangler.jsonc, wrangler.json or wrangler.toml, a framework's Cloudflare adapter, or a Node.js server run as a Worker), static (a site a build writes), html (the files as they are), container (a server that is not run as a Worker, a framework set up to need a server, or a Dockerfile with nothing else to serve) or none (nothing to serve). |
framework | The framework it is built with, from the table below; node for a Node.js server run as a Worker; for a container without one, dockerfile, or the server g1t writes a Dockerfile for (node, django, flask, fastapi, python, go, rails, rack, laravel, php). Empty when there is none. |
dockerfile | A container's own Dockerfile, relative to the project. Empty when g1t writes one, and for anything that is not a container. |
port | The port a container listens on: its Dockerfile's EXPOSE, else 8080. |
entry | For a Node.js server run as a Worker, the file that starts it, relative to the project. Empty for anything else. |
install | How dependencies are installed, from the lockfile: npm ci, pnpm install --frozen-lockfile, and so on, and bundle install for Jekyll. Empty when there is nothing to install. |
build | What builds it: your command, the package's build script (npm run build), the framework's own command, or wrangler deploy --dry-run for Workers. Empty when nothing does. |
output-dir | The folder served, relative to the project (. for the project itself): yours, a Workers project's assets directory, the folder the framework writes, or the first of dist, build, out, public, _site, .output/public that exists. Empty when a build has yet to write it, as for a Cloudflare adapter's Worker. |
When kind is none, the step's log says what to change or add, such as
a Dockerfile. Docker deployments
has the order in which a project's kind is decided.
Frameworks
framework | Found by | Serves |
|---|---|---|
vite, vite-react, vite-vue, vite-svelte, vite-solid, vite-preact | vite, and the framework's Vite plugin | dist, or build.outDir |
astro | astro | dist, or outDir; a Worker with @astrojs/cloudflare |
nextjs | next | out with output: 'export'; a Worker with @opennextjs/cloudflare and a wrangler.jsonc |
sveltekit | @sveltejs/kit | build with adapter-static; a Worker with adapter-cloudflare |
nuxt | nuxt | .output/public, from nuxi generate |
react-router, remix | @react-router/dev, @remix-run/dev | build/client with ssr: false |
gatsby | gatsby | public |
docusaurus | @docusaurus/core | build |
eleventy | @11ty/eleventy | _site |
angular | @angular/core and angular.json | dist/<project>/browser |
create-react-app | react-scripts | build |
hugo | hugo.toml, or Hugo's config.toml | public |
jekyll | _config.yml and a Gemfile | _site |
mdbook | book.toml | book |
What deploys has
each one's build command. Your build-command and output-dir win over
what is detected.
It runs g1t-runner detect, found or downloaded as g1t/deploy finds it.