History, tags and pull requests

Deskless 3.0 is available for iPhone and iPad. Android 3.0 is in review on Google Play; Android 2.1 supports pull requests on GitHub and Forgejo/Gitea only, without the review, checks, merge and issue tools. These Git tools require Deskless Pro.

Inspect a file’s history

Open the repository folder and a tracked file, then choose Blame & History from the editor menu. Switch between Blame and History. Blame associates lines with commits; uncommitted lines are identified separately. Select a commit to inspect its message and file changes.

For repository-wide history, use the Git panel’s History view. Review the diff before basing another change on an older commit. These local views do not require a network connection once the repository is present.

Create and publish a tag

Open Git → Branches, find Tags, then choose New Tag. Enter a name such as v2.1.0. An optional message makes an annotated tag; the tag points at the current commit.

Use a tag’s menu to Push Tag or Delete Tag. Creating a tag is local until you push it. Deleting a local tag does not remove a previously pushed tag from the server. Pushing requires network access and write permission on the remote.

Rebase a branch

Save and review your work first. In Branches, open the target branch’s context menu and choose Rebase [current branch] onto [target]. On Apple devices, touch and hold the branch; Android provides a branch menu.

A rebase replays your current branch’s commits and gives them new hashes. Coordinate before rewriting commits other people already use. If a conflict stops the operation, resolve the files in the Git Commit view, stage the resolutions, then return to Branches → Continue Rebase. Abort Rebase abandons the in-progress rebase.

Supported hosts

Pull and merge requests work with GitHub.com, GitLab (GitLab.com, including nested groups, and self-managed instances you configure) and Forgejo/Gitea-compatible hosts. General Git clone/push support is broader: a Bitbucket, Azure DevOps or other Git remote does not imply a supported review integration. GitHub Enterprise is not included in the GitHub.com integration.

For a self-managed GitLab instance, open the repository’s pull-request or issue panel, choose Forge Provider on Apple devices or Change provider on Android, select GitLab and save its HTTPS address.

View or create a pull request

1. Open a repository with a supported remote.
2. Add an HTTPS access token for that host in Settings → Git Credentials on Apple devices, or Settings → Git → Git Credentials on Android. A saved SSH key does not replace the API token. Public GitHub listings may be readable without one; private access and creation require suitable permission.
3. Open the Git panel’s Pull Requests view and inspect an existing request, or choose New Pull Request.
4. Push the source branch first. Confirm the base branch, title and description, then choose Create.

Review a pull or merge request

1. Open a request to see its description and CI checks: commit statuses on GitHub and Forgejo plus GitHub check runs, and GitLab pipelines.
2. Choose Check Out Locally to fetch the request into a local branch (pr-N, or mr-N on GitLab) and run it on the device. Checkout verifies the exact commit you reviewed and refuses to overwrite uncommitted work or unsaved drafts.
3. Choose Review Changes to read the diff with existing comments, replies and resolved or outdated threads. Add inline comments and suggested changes, then submit Approve, Request Changes or Comment. On GitLab, Request Changes opens in the browser.
4. Preview a reviewer’s suggestion and apply it to a local draft. Applying never saves, commits or pushes for you.
5. Choose Merge and confirm. The merge is pinned to the head you reviewed; if the branch has changed, refresh it and review the new commits first. The host’s own merge rules still apply.

Checks, logs and the agent

Open a check to read its log tail: GitHub Actions logs, Forgejo Actions runs and jobs (Forgejo 16 or later), and GitLab pipeline jobs, including pipelines that run in a fork. Deskless does not start pipelines or retry jobs.

When a check fails, Fix with Agent opens Agent Mode with the failing check and its log tail as context. The Agent Mode review rules still apply: nothing changes until you approve it.

Issues and Start Work

The Issues tab lists open issues. Start Work creates a branch named after the issue (issue-N-…) and can seed Agent Mode with the issue as its goal. Some actions, such as creating a merge request from a fork into another project, open the host’s browser interface instead.