You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* fix(GitClone): produce the same outputs from a local checkout as from a clone
Two ways a local checkout silently came up short of the clone path's outputs,
leaving downstream blocks stuck on "Waiting for outputs from: … (repo_owner,
org_id, repo_name, repo_id)".
Remote resolution only ever looked at `origin` (GitClient.getInfo). A checkout
that names its remote something else — a fork whose upstream is the interesting
one, a repo re-pointed after `git init` — yielded no remote at all, so there was
no repo_owner/repo_name, and no org_id/repo_id either, since those are looked up
from the owner and name. inspectLocalRepo now falls back to whichever remote the
repo does have. `origin` is still preferred, so remote order decides nothing in
the common case.
The org/repo ids are resolved once, at confirm time, from the session token.
Because selecting a checkout deliberately didn't wait on the linked auth block,
confirming before authenticating produced a block permanently missing org_id and
repo_id. Confirming now waits for the auth block exactly as cloning does; the
path field, the folder picker, and the inline "is this a git repo?" check stay
usable while it's pending, since none of those need credentials.
Docs updated: the local source no longer claims to need no credentials, and the
no-remote caution now names the outputs that go missing with it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(GitClone): stop the local-checkout preview from reading as a finished block
The "is this a git repo?" check rendered in the same green success styling as
the completed state — check icon, root, remote, branch, file count — so a
checked directory looked like a block that had run. It hasn't: nothing is
registered and no outputs exist until "Use This Repo" is confirmed, and a block
that has produced no outputs leaves every consumer reporting each referenced
name as missing ("Waiting for outputs from: clone_repo (repo_owner, org_id,
repo_name, repo_id)") — which reads as the outputs being unsupported rather than
the block being unfinished.
The preview is now informational rather than success-styled, green being
reserved for the completed state, and says outright that the directory is not in
use yet. The no-remote warning names the outputs that go missing with it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* uptick to 0.21.1
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(GitClone): address review — docs contradictions and interrupt-safe git queries
Three findings from the review of #195.
The docs said choosing a directory "reads it only" and in the same sentence that
it "registers the repo exactly as a clone would" — the contradiction at the
heart of the reported bug. Inspection and confirmation are now described as the
separate steps they are, including that a block which hasn't been confirmed has
produced nothing and leaves its consumers reporting missing outputs.
The integration paragraph still said a pull request opens against the checkout's
`origin` remote, which contradicts the new fallback two paragraphs below it. It
now says "the checkout's remote".
firstRemoteUrl spawned git without ever killing the child, so an interrupted
fiber would orphan it. Rather than plumbing a Scope through inspectLocalRepo and
the handler — which would leave this helper inconsistent with countFiles three
lines away, which has the same property and is shared with the clone path —
the shared readGitLines helper wraps its drain in Effect.ensuring(kill). Same
guarantee, no signature change, no interruption path exists today anyway: on the
normal path the process has already exited and the signal is a no-op.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Add a bootstrap for new repositories with no commits
* uptick to 0.21.2
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(GitClone): address review — spellcheck, best-effort hasCommits, unique input id
- docs: "colour" → "color" in GitClone.mdx. cspell runs US English and it
was the only occurrence, so the whole Documentation Tests job failed
before build or linkcheck ran.
- electron/main/ipc/git.ts: wrap the clone flow's hasCommits query in
Effect.orElseSucceed(() => true), as every other caller already does.
Bare, a failed query failed the whole git:clone program after the clone
had already landed on disk — the user saw an error, the worktree was
never registered, and the outputs were lost. Defaulting to true also
matches the domain rule that an unreadable repo counts as having
history, so nobody is offered a seeded branch by mistake.
- EmptyRepoWarning: derive the branch input's id from useId() instead of
the literal "empty-repo-branch". Two GitClone blocks on empty repos in
one runbook produced duplicate ids, so both labels pointed at the first
input.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: docs/src/content/docs/authoring/blocks/GitClone.mdx
+18Lines changed: 18 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -128,6 +128,24 @@ Set `showFileTree={false}` if you don't want the cloned repository to appear in
128
128
129
129
A local checkout registers with the workspace the same way. Note that the **Changed** tab then shows any uncommitted changes the checkout already had, not just the ones the runbook makes.
130
130
131
+
### Repositories With No Commits
132
+
133
+
A repository that was created but never pushed to has no branches at all. Nothing downstream can open a pull request against it: the base branch a pull request needs does not exist, and the provider rejects the request as invalid — after the runbook has already committed and pushed its work.
134
+
135
+
GitClone detects this case for both sources. When the repo has no commits, the block:
136
+
137
+
- renders in the warning color rather than reporting a plain success,
138
+
- withholds its outputs (including `clone_path`) and does not register the repository with the workspace, so blocks that depend on it stay blocked,
139
+
- offers a **Create default branch** button that pushes a single empty commit to the branch the remote advertises as its default. The name is editable before you press it.
140
+
141
+
Once the branch exists, the block releases its outputs and registers the workspace exactly as it would have for a repository that already had commits, and the runbook continues.
142
+
143
+
The seeded commit is deliberately empty. It gives the default branch something to point at, so the branch the runbook pushes later shares an ancestor with it and opens as a reviewable diff instead of an unrelated root commit. Files already written into the work tree are left untracked, not swept into it.
144
+
145
+
<Asidetype="note">
146
+
Seeding requires a linked auth block, since it pushes to the remote. The branch is created locally, committed, and pushed to `origin` in one step.
147
+
</Aside>
148
+
131
149
### Accepted Git URL Formats
132
150
133
151
The GitClone block accepts the following URL formats:
0 commit comments