Notebook Git Access

Before you start

You need a Syntasa credential holding one of two things: a personal access token for https:// remotes, or an SSH private key for git@ remotes. Create one under Resources → Credentials.

One credential can serve several repositories, and one repository can use a different credential for each person who works on it. Nothing you set here is visible to, or usable by, anyone else in the workspace.

The first time you use a repository

Clone, pull or push as usual. When git needs a credential, Syntasa asks you for one.

1. Choose the credential. Only credentials you can open are listed. If the list is empty, create one first — the dialog tells you where.
2. Choose the key inside it. A credential can hold several secrets; pick the one holding your token or private key. Some credential types ask you to type the key name rather than pick it from a list.
3. Set the git username — HTTPS only, and only some providers care. See the table below.
4. Confirm. Syntasa tests the credential against the real repository before saving it. If the provider refuses it, the dialog reopens and explains why. Nothing is saved, and nothing is left half-working.

After that, the same repository authenticates without asking again.

What gets saved

The name of the credential and the key inside it. Never the token, never the private key.

That reference is stored with the workspace, so it survives a pod restart. The secret itself is resolved in your browser, with your own session, at the moment an operation needs it — and is gone when the operation ends. Because what is stored is a pointer rather than a copy, revoking a token or rotating a key takes effect immediately. There is no cached credential to catch up.

Which git usernameHTTPS

Providers disagree about whether this field matters, and a correct token with the wrong username fails in a way that looks identical to a bad token. This is the single most common thing to get wrong.

Never your email address on Bitbucket, for either kind of token. Bitbucket accepts the request and then refuses access, which reads like a permissions problem rather than a username one.

Your own SSH keySSH

Pick the credential holding your private key. For the length of one git operation, Syntasa starts a private SSH agent, loads your key into it, runs git, then destroys the agent. The key is never written to the workspace filesystem and never outlives the operation.

The public half of that key must be registered on your own account with the provider. A key that works from your laptop works here unchanged.

If you previously relied on the shared key, pushes would ask for a credential the next time you use them. Add your own key as a Syntasa credential and select it once.

One repository, two ways in

A saved credential is tied to the transport it was made for. https://github.com/team/repo and git@github.com:team/repo are remembered separately, so a token for one and a key for the other can both exist without overwriting each other.

It also means a token is never offered to an SSH remote. That mismatch would fail as Permission denied (publickey), which tells you nothing about having picked the wrong kind of secret.

Cloning, including submodules

The clone dialog takes the repository URL and asks for a credential the same way a push does. Cloning a private repository no longer shows git's own username-and-password prompt.

Include submodules now works over HTTPS as well as SSH. Your credential answers every prompt git makes — in the parent repository and in each submodule, however many there are.

It answers only for the host you authorized. A submodule pointing at a different host is refused rather than authenticated, so git reports a failure instead of your token reaching a server you never chose.

Who your commits belong to

Both the author and the committee on every commit are you: the name and email from your Syntasa account.

Previously the committer was recorded as the workspace, so a shared workspace's history showed the same name on everyone's work even when the author line was right. It no longer does — on the commit, and on the push that carries it.

Changing a credential later

Right-click in the git panel, or open the command palette, and choose Set git credential for this repository. Pick the repository, then pick again.

Use this when a token has been rotated, a credential renamed, or the wrong one selected. A stale binding does not fail loudly on its own — the panel cannot tell — so this is the way back in.

When something fails

The dialog leads with what the failure means and keeps git's own output under What git reported. The common ones:

• Permission denied (publickey)

  The SSH key was refused. Either it is not the key registered with your account on that host, or that account has no access to the repository. Check the public half is on your account before changing credentials.

• You may not have access to this repository

  Bitbucket's wording when the token is fine but the git username is not the one that token requires. Check the username against the table above before assuming the token is wrong.

• Invalid username or password

  Either the token is wrong or expired, or the git username does not match the account it belongs to. Both are worth checking — they fail identically.

• Repository not found

  Providers report a private repository you cannot see as missing rather than forbidden, so this is usually an access problem, not a typo. Confirm the URL, then confirm the credential has access to it.

• Host key verification failed

  Not a credential problem, and the one case where picking a different credential is the wrong response. The host's key changed or is unknown. Verify the host before retrying.

A word on speed

Workspace storage is backed by object storage rather than a local disk. Git operations that touch many files — git status, switching branches, the first refresh after a clone — take noticeably longer than the same command on a laptop, and large repositories feel it most.

Operations queue rather than fail. Give a branch switch or a first status time to finish before retrying it; running the same command again puts it behind the one already in progress.