Code, Git & files

The editor panel is built on Monaco, the same editor that powers VS Code, with a file tree on the left and a tab bar across the top. Click a file in the tree to open it; tabs show a dot when there are unsaved changes.

• Preview vs. pinned tabs: a single click opens a file in a temporary (italic) preview tab; double-click to pin it.
• Save with Cmd/CtrlS. Saving an untitled buffer prompts for a location. Turn on Format on save in Settings to tidy files automatically.
• Markdown preview: .md and .mdx files get a preview toggle in the top-right corner.

Source control lives in two places that share the same rows, the same commit box and the same actions: the sidebar, and the notebook’s Source Control page. Both show your working tree as sectioned Staged, Unstaged and Untracked rows, each file tagged with a status badge and its own +N and −N line counts. Click a file to open its diff; use the section buttons to stage or unstage everything.

Below the file rows sits a sticky Commits dock: a timeline of recent commits with ref chips for the branch, tag or pull request that points at each one. A commit row expands inline to the files it touched, and Show older commits pages further back. The dock keeps its place however long the file list grows, so history is never pushed out of reach.

Under the header, a sync strip tells you what is still outstanding between this checkout and its remote, and carries the button that resolves it: 3 commits to push with a Push, my-branch is not on origin yet with a Publish branch, or 2 commits to pull with a Pull. A branch that has drifted both ways names both halves and offers Pull first. When there is nothing outstanding the strip is not there at all.

A commit box sits at the bottom. Write a message and press Cmd/CtrlEnter (or click Commit) once something is staged. Committing on its own is fine: once it lands, a Push now button appears right under the box, so you never have to go looking for a way to send the commit up. Amend last replaces the previous commit instead of adding one and pre-fills its message, and it works with nothing staged when all you want is to reword.

In the header, Pull only appears when there is something to pull from, Push counts what is waiting (Push 3) and reads Publish branch while the branch has no upstream yet, and a pull-request or merge-request chip can appear beside them when your branch has one open.

The canvas Git panel keeps the older three-tab layout: Changes, Log and Branches, with the same header, sync strip and commit box.

Two of the small chores around a commit can be handed off. A Generate button in the commit box drafts a message from what you have staged, and the new-branch form turns a plain-language description (“fix the flaky upload retry”) into a branch name in your repository’s style.

Both run only when you click them, never in the background, and both leave the result editable, so it is a first draft rather than a decision. The staged diff is read where it lives and only the drafted text comes back.

The Commit button is a split button. Its menu chains the steps you almost always run together, then streams the run back to you step by step so you can see exactly where it got to:

• Commit & Push, which becomes Commit & Publish branch when the branch has no upstream yet.
• Commit, Push & Pull request, which runs the same two steps and then creates the request through your forge’s CLI. On a GitLab remote the entry reads Commit, Push & Merge request.

The entry is named in your forge’s own vocabulary. Where Deska cannot act, it stays visible but disabled with the reason attached: no remote at all, a forge Deska does not drive, or the forge CLI not installed. On GitLab the entry notes that Deska cannot create merge requests there. Today GitHub is the forge Deska can complete the flow on, through the gh CLI.

The File Explorer panel is a file browser, not a project tree. It opens on the folder your worktree is checked out at and goes anywhere from there: into a folder, back out of it, and above the project, across the whole disk.

• Double-click a folder to open it. The folder name in the toolbar is a menu of every folder above this one, and the path bar along the bottom walks back out one click at a time.
• Three views. Icons (with previews for images), a list with sortable Name, Date Modified, Size and Kind columns, and columns for walking several levels at once. Each panel remembers its own.
• Places down the side. Home, Desktop, Documents, Downloads, Applications, your open projects and any mounted volume. Right-click a folder to add it to Favorites.
• The keyboard works. Arrows move, Enter opens, Cmd/CtrlUp goes to the enclosing folder, Cmd/Ctrl[ and Cmd/Ctrl] are back and forward, and typing jumps to a name.
• It still knows about Git. Inside a repository, file names carry the same status letters (modified, untracked, deleted, conflicted) the rest of Deska uses.
• Right-click for the full menu: new file or folder, rename, duplicate, copy, paste, delete, open in a terminal, open as a project, or reveal in your system file manager. Hidden files are a toggle in the view options.

1. Open a file from the file explorer and make your edits in the editor.
2. Save with Cmd/CtrlS.
3. In the source-control sidebar (or the Git panel’s Changes tab), click the file to review the diff, then stage it.
4. Write a commit message (or generate one) and press Cmd/CtrlEnter.
5. Push from the Git header, or use the Commit split button to commit, push and open the pull request in one run.

Diffs are read-only and side by side: original on the left, your working copy on the right, additions in green and removals in red. To edit, open the file normally instead of through the diff. Where the diff appears depends on where you clicked:

• From the file tree inside an editor panel, the diff opens as another tab in that same editor, marked as a diff in the tab strip. Your other tabs stay exactly where they were, and a path is either a normal tab or a diff tab, never both.
• From the Git panel, the source-control sidebar or a standalone File Explorer, the diff opens as its own editor docked in the center zone, titled after the file with Staged Diff or Working Diff.

From the notebook’s Source Control and Explorer pages, the diff opens as a stop inside that same page rather than a docked editor, so the review stays on the notebook’s own trail.