Pushing Your Work
When the assistant edits a repository, its commits stay inside the conversation's own private workspace — nothing reaches your Git remote until you push it yourself. Pushing is never something the assistant does on its own: it happens only from the Push button, and the credential it uses never reaches the assistant or its sandbox.
This feature may not be available in all setups. If you don't see the Push button in the conversation header, it may not be enabled by your administrator.
Opening the push dialog
Click the Push button in the header (or use the header menu on narrow screens, where it appears as a Push item). A badge on the button shows how many commits are waiting to be pushed; a small dot marks a repository with uncommitted changes. Clicking it opens the "Push committed work" dialog. When more than one repository has something to show, each gets a tab under the title, with a small mark saying where it stands: ↑ and a count for commits ready to push, a warning sign when it needs you (the branch moved, a push was refused, no credential), a hollow dot for uncommitted changes only, and a check mark once pushed. The arrow keys move between tabs.
Committing changes first
If the conversation's workspace has uncommitted changes, the dialog lists them before anything else, with a Review changes panel showing the file diff and a Commit button. Clicking Commit sends the assistant a chat message asking it to commit — pushing itself never commits on your behalf.
If a workspace is dormant (for example after a server restart), its uncommitted changes can't be read until it's reactivated. The dialog says so rather than claiming there's nothing to commit; send a message in the conversation to bring the workspace back, then commit.
Reviewing and pushing commits
Each repository with commits ready to push shows:
- A small picture of the push at the top: your commits as dots on the left (This session; hollow dots are uncommitted files, which stay behind), a line to the right, and the target branch on origin where the line ends. The line shows what is happening: it marches while the remote is being checked, the dots travel along it while pushing, and it turns green with the dots landed on origin once pushed. If your system is set to reduce motion, the picture changes without animating.
- The target branch is the rounded field where the line ends, pre-filled with a suggested branch name (or the conversation's original branch); click it to type another one. If it is
main,masterortrunk, it gets a warning outline, and if the session started on such a branch, the dialog suggests pushing to a new branch instead. - One line under the picture saying what is going on, with any longer explanation (or git's own output) behind a link such as What changed? or Show git output.
- The list of commits (short SHA and subject).
- Review changes / Hide changes to expand a full diff of what the push would add, with Expand all / Collapse all for the file list.
- A Key passphrase field, shown only when the repository's credential is an SSH key — sent once with the push and never stored.
- One button at the bottom that says exactly what it will do, such as Push 3 commits to develop. A button that is known to fail is never offered: without a push credential it becomes Set up a push credential, and after a refusal Check again.
Repositories a plugin manages on its own (such as the organizational memory knowledge base) don't appear in this dialog — they're committed and pushed on their own schedule, not from here.
When the remote branch has moved on
Pushing here is always fast-forward: there is no force-push option anywhere in this flow. If someone else has pushed to the target branch since your conversation started, git refuses the push rather than overwrite what's on the remote, and the dialog offers three ways forward:
| Option | What it does | Touches the remote? |
|---|---|---|
| Push to a new branch | Pushes to a fresh, suggested branch name, leaving the moved branch as it is | Only adds a new branch |
| Merge the remote changes in, then push to "‹branch›" | Previews the merge, then (on confirm) pushes a merge commit built host-side | Yes — adds a merge commit |
| Bring "‹branch›" into this session's workspace | Brings the remote branch into the conversation's own workspace so the assistant continues from current code | No |
One of the three is always selected — the one you picked last time, otherwise the new branch — and the picture at the top redraws to show it before anything runs: the target becomes NEW ‹branch›, a merge mark appears on the line, or the arrow turns around to point into your session.
The merge option ("reconcile") is a deliberate two-step action: Preview the merge opens a page of its own inside the dialog that shows exactly what the merge would add, with no conflicts, before a separate Merge & push confirms it. If merging conflicts, no merge push is offered — the page lists the conflicting files, offers pushing to a branch of your own instead, and links to updating the workspace (the only path with a resolver). Back, the arrow next to the title, or Esc returns to the three options.
Updating the workspace is one click, since it changes nothing on the remote and can be undone with ordinary git. If it conflicts, the dialog opens a page naming the conflicting files and — only as a further, explicit step — offers to let the assistant resolve them. The assistant's resolution is then shown as a diff; read it, and Keep it — back to push returns to the push, which carries the merge along.
Push history
The clock icon in the dialog's header opens your Push history: your recent push attempts across all conversations, newest first, as a timeline. Each entry names the repository, target branch, short SHA and time, and lists the commits it carried (or, for a failed attempt, the ones it tried to carry); its dot is green for a push, a hollow green ring for a push whose commit the merge step above authored ("Merged & pushed"), and red for a failure, whose git output is one Show git output click away. Back, the arrow next to the title, or Esc returns to the push.
Setting up push credentials
Push credentials are configured per user, under Settings → SCM Push.
Commit identity is the name and email stamped on commits the assistant makes on your behalf. It's pre-filled from your profile the first time; click Save identity to confirm it (or change it).
Push credentials link a repository (or a glob such as team/*) to a host-only user secret and the branches it's allowed to push to — nothing here is ever exposed to the assistant. To add one:
- In your Git host (Gitea/GitHub/GitLab), create an access token with write access to the repository.
- Add it under Settings → User Secrets as a new secret, with Host-only ticked.
- Back in Settings → SCM Push, click Add credential, choose the repository and that secret, and save.
Token credentials push over HTTPS; Codumentor converts an ssh:// remote to its HTTPS form automatically, so the Push URL field is usually left blank — set it only to override the target.
Using an SSH key instead
Choosing SSH key as the authentication method reads the secret as a private key (the full PEM block) instead of a token. Two things are specific to this method:
- Known hosts — pasting the server's SSH host-key line (from
ssh-keyscan -p <port> <host>) pins it, protecting the connection against a man-in-the-middle. It's optional but recommended. - The key's passphrase, if it has one, is entered in the push dialog itself at push time — never stored.
An Allowed branches glob (e.g. codumentor/, feature/) restricts which branches a credential may push to; leave it blank to allow any branch.
Pushing is deliberately kept out of the assistant's own hands: git push always counts as network access under Permissions, so it's never something a shell command run by the assistant can do — only this dialog can.