Clones, worktrees and opening in your tools

Every pull request page has a row of buttons in its header: your code editor, your terminal, your AI assistant (such as Claude Code or Codex CLI) and your file manager. Click one and the pull request's code opens there, at the pull request's head commit. You don't need to look up the branch, fetch it or run git checkout.

What opens depends on whether Revue knows where your clone of the repository is:

The open buttons#

The buttons sit in the pull request's header, and also in a repository's header (see Opening a repository in your tools).

• Click the button to use your default app. Its tooltip says which app and folder, for example "Open the worktree /home/you/code/web-fix-login in Visual Studio Code".
• Click the arrow beside it to pick another app from the ones Revue found. The arrow only shows when Revue found two or more. The app you pick becomes your new default.
• While the app starts (or the source downloads), its button shows a spinner. Revue opens one thing at a time.

Editors with Revue Companion. When an editor with the Revue Companion plugin is running (a JetBrains IDE today: IntelliJ IDEA, WebStorm, PyCharm, RustRover…), the editor button goes to it instead of starting an editor, even when your default editor is another one. See Which editor opens for which one when several run. In that editor:

• If one of its windows has a repository of the pull request's repository with the pull request's branch checked out (or has the folder open), that window comes to the front, with the file at its line when there is one.
• Otherwise it opens the folder in a new window.

An app picked from the arrow's menu opens as before: a JetBrains IDE picked there is asked only if it's running with the plugin. When no editor runs the plugin, or the one chosen doesn't answer within a second or so (it was just closed), Revue starts your default editor as before. Revue only talks to the editors on your computer (127.0.0.1, the ports 63342 to 63361 that JetBrains IDEs listen on).

Advanced: what each button opens, step by step

On a pull request page, a click goes through these steps:

1. If a worktree of your clone has the pull request's branch checked out (or is at its head commit), Revue opens that worktree.
2. Otherwise, if the pull request's source is already in the cache for its current head commit, Revue opens it. If you have a clone set, only a checkout made from your clone counts. An old download in the same place is replaced.
3. Otherwise, with a clone set, Revue checks the head commit out from your clone (Checking out source…), fetching it first if the clone doesn't have it. Then it opens it.
4. Without a clone, Revue downloads the source at the head commit (Downloading source…), with a small progress circle in the header, and then opens it.

If something fails, the page shows Couldn't download the source: … or Couldn't check out the source from your clone: ….

The small icon left of the buttons (shown when there's no worktree) says what a click will open:

Icon	Tooltip
Cloud with arrow	Source not downloaded: the editor and terminal download the PR's head commit first
Check mark	Source downloaded: the editor and terminal open the PR's head commit right away
Folder	The editor and terminal check out the PR's head commit from your clone first (fetching it if the clone lacks it)
Check mark (with a clone)	Source checked out from your clone: the editor and terminal open the PR's head commit right away

The source copies (downloaded or checked out from your clone) live in Revue's cache:

System	Folder
Linux	~/.cache/revue/sources/ (or $XDG_CACHE_HOME/revue/sources/)
macOS	~/Library/Caches/revue/sources/
Windows	%LOCALAPPDATA%\revue\sources\

Each repository has a folder (owner-repo), and each pull request head a folder in it named pr-<number>-<branch>-<first 8 characters of the commit>, for example pr-42-fix-login-1a2b3c4d. The branch part is at most 24 characters, with / turned into _. Revue keeps the 3 most recently used pull request checkouts per repository and deletes older ones. You can clear them all in Settings → Storage → Cache → Source checkouts → Clear.

Large files: files over 2 MB are never put into a downloaded copy. For Bitbucket accounts signed in through the browser, large non-text files over 1 MB can be left out too. See Settings → Storage → Large files in sources and Browsing code.

Setting a local clone#

A local clone gives you real worktrees, and the Code tab reads the source from your clone instead of downloading it.

You can set one in three ways:

• Clone the repository from Revue. See Cloning a repository.
• Point Revue at a clone you already have. Open Settings, pick the repository under Repositories in the sidebar, and use the Local clone card. Type the folder, click Choose…, or click Detect.
• Detect clones for every repository at once with Detect clones for all in the Settings sidebar.

A clone belongs to its repository whatever the case of the name: one set for Acme/Web is used for acme/web too, as services ignore the case and some links lowercase it.

Shortcuts to the card: the repository page's gear (Repository settings), or the yellow warning icon in a pull request's header when no clone is set.

Once a folder is saved, the card checks it. A green check says Git clone of owner/repo (remote origin). PRs here can find and create worktrees of their branch. Otherwise it shows why, for example Folder not found, Not a git repository or No remote of this clone points at owner/repo.

Advanced: how Detect finds a clone

• Detect (one repository) searches the parent folders of your other clones first, then your whole home folder. When it finds a clone it saves it right away. When it doesn't, it says Couldn't find a clone of owner/repo in your home folder. Choose its folder instead.
• Detect clones for all searches the same places in one pass for every repository listed in Settings. Then it opens a Detected clones dialog, and nothing is saved until you click Apply. Each clone found is listed with its folder and either New: no clone was set or Replaces . Clones that would replace a folder that still exists start unticked. Repositories with nothing found are listed under No clones found for N repositories. Click Apply (N clones) to save the ticked ones, or Cancel to change nothing.
• A folder counts as a clone when it has a .git folder and a remote whose address names owner/repo. A clone whose origin matches wins over one where only another remote does, and a shallower folder wins over a deeper one.
• The search goes at most 6 folders deep and reads at most 50,000 folders. It skips hidden folders, node_modules, target, Library, AppData, Applications and snap, worktrees and submodules, and anything inside another repository.

Advanced: which remote counts, and where the setting is kept

• In a pull request, Revue uses the clone's remote whose address points at the repository on the right service: github.com, bitbucket.org or your Forgejo server's host name. Both HTTPS and SSH addresses work ([email protected]:owner/repo.git, https://user@host:3000/owner/repo, ssh://git@host:2222/owner/repo.git). SSH host aliases without a dot (such as github-work) are accepted. When several remotes match, origin is preferred.
• The Local clone check in Settings only looks at owner/repo, not the host.
• Clones are saved in the local_repos setting (owner/repo → folder). By default it's shared with your other computers. Click the card's Shared switch to keep it on This computer only. A folder that doesn't exist on the current computer is ignored there. An export of your settings leaves it out. See Files, sync and settings for one computer.
• When the service can't load a repository, the repository page reads branches, history and code from your clone instead, with a Showing your local clone at … banner. Without a clone, it offers Set a local clone. See Repositories and branches.

Cloning a repository#

On the Repositories page, hover over a repository that has no clone yet and click the download icon at the end of its row. Its tooltip says Clone this repository, signed in as its account (Settings → Storage sets where).

Revue then:

1. Picks the folder to clone into (or asks you with a Clone here folder picker if none is set).
2. Runs git clone into a folder named after the repository, for example ~/code/web. A notice says Cloning owner/repo into ….
3. Saves the new folder as the repository's local clone, so worktrees and the Code tab use it right away.

Once cloned, the row shows a folder icon with Cloned in ….

Signed in as the right account#

The clone's remote names the account the repository is listed for, for example https://[email protected]/acme/web.git. Git and its credential helper then use that account's sign-in for this clone and every fetch and push after it. That matters when you have two accounts on one service, such as work and personal.

Revue never waits for a password prompt. If git has no sign-in for the account, the clone fails with git has no sign-in for this account. Sign in for git (for example with the service's credential manager or CLI), then clone again.

Where repositories are cloned#

Set the folders in Settings → Storage → Where repositories are cloned:

An account's folder wins over its service's, and a service's over the default. Use Choose… to set a folder and × (Clear) to remove it.

Advanced: cloning details

• Clones always use HTTPS: https://<user>@github.com/…, https://<user>@bitbucket.org/…, or your Forgejo server's address (including its port and path). Characters in the user name that aren't allowed in a URL are percent-encoded.
• It's a plain, full git clone of the default branch.
• A folder typed as ~ or ~/… means your home folder.
• If the destination folder already exists and is a clone of the repository, Revue uses it (owner/repo is already cloned in …: using it). If it's anything else, Revue leaves it alone and says Couldn't clone owner/repo: … already exists.
• Clone folders are always kept on this computer only (never synced or exported).
• Saving a clone also gives the language servers a first look at the repository. See Language servers.

Worktrees for a pull request#

A worktree is a second working folder of the same clone, with another branch checked out. Revue can create one per pull request, so you can run, edit and commit to the pull request's branch without touching what's checked out in your main clone.

Creating a worktree#

When a clone is set and no worktree has the pull request's branch yet, the pull request header shows Create worktree.

Click Create worktree. There's nothing to confirm: hover the button to see what it does (Fetch and check it out in a new worktree of , in a folder beside it.).

Revue fetches the branch, creates the worktree and says Worktree created in …. The header then shows a green chip with the branch name, and the open buttons open the worktree. Click the chip to copy the worktree's path (Worktree path copied).

Revue only creates worktrees when you ask. It never makes one on its own.

Where worktrees go and how they're named#

The worktree goes in a folder beside your clone, named <clone folder>-<branch>, the same place git worktree add ../<name> would put it:

The local branch has the pull request's branch name. When a fork's branch has the same name as the target branch (main into main), it's called pr-<number> instead, for example pr-42.

Worktrees you already have#

Revue looks for an existing worktree before offering to create one. Any worktree of the clone counts, including your main clone folder, if it has a branch of that name checked out or sits at the pull request's head commit. So a worktree you made yourself with git worktree add is found and used too. Revue looks again whenever it checks the pull request for updates, so worktrees made or removed outside Revue are picked up.

New pushes to the pull request#

Each time you open the pull request's worktree (the editor, terminal, AI assistant or folder button, or Reveal in code editor), Revue first brings it up to date, as git pull --rebase --autostash would. The button spins meanwhile.

• Behind the pull request: Revue fetches the branch the worktree's branch tracks (for a fork's pull request, which tracks nothing, the pull request's head, fetched as when creating it) and moves the worktree to it. Your own commits go on top of the pull request's new ones (a rebase), and your uncommitted changes and untracked files are set aside and put back. It says Worktree updated to the pull request's latest commits.
• Already up to date, or only ahead (commits of your own and nothing new): nothing changes.

Revue leaves the worktree exactly as it was and opens it anyway, saying why in a notice, when:

• Your commits conflict with the pull request's new ones: the rebase is undone (git rebase --abort), so the branch, the files and your uncommitted changes are back as they were. Update it yourself, for example with git pull --rebase in the terminal, and resolve the conflict there.
• Your uncommitted changes touch files the new commits change: commit or stash them first, then open it again.
• It can't fetch (offline, or the branch was deleted on the server).
• It's in the middle of a rebase, merge or cherry-pick.

A worktree that's detached (not on a branch), or on another branch than the pull request's, is opened as it is. Revue never pushes, and never runs an interactive rebase: no editor opens, whatever your git settings say.

The source copies in the cache are different: each head commit gets its own copy, so after a push the buttons open a fresh copy of the new head (when there's no worktree).

Removing worktrees#

Revue lists the worktrees it created under Worktrees created by Revue in the repository's Local clone card in Settings. Each row shows revue: owner/repo#42 · <branch> and the folder.

1. Click the trash icon (Delete worktree) on the row.
2. Read the confirmation: and any uncommitted changes in it are deleted. The branch is kept.
3. Click Delete worktree.

Revue never deletes a worktree without asking. It only deletes worktrees it created. Worktrees you made yourself aren't listed and can't be deleted from Revue.

When the pull request is merged or closed#

When Revue sees that a pull request is merged or closed (on opening it, or while its page is open) and it has a worktree Revue created for it, the page asks Pull request merged: delete its worktree? (or Pull request closed: …). The question says where the worktree is and what deleting it would lose:

• It has N uncommitted changes, which deleting it loses. Edited, staged and untracked files.
• Its branch has N commits that aren't pushed. The branch is kept either way. Commits on no remote branch that aren't part of the pull request.
• Everything in it is committed and pushed. When neither applies.

Click Delete worktree to delete it (as from Settings: the branch is kept), or Keep to leave it. Revue remembers Keep (in the worktree's admin folder) and doesn't ask about that worktree again. If you close the question with Esc, Revue asks again the next time it starts. Each worktree is asked about at most once per session.

Advanced: how the branch is fetched (forks included)

When you create a worktree, Revue:

1. If your clone already has a local branch of that name, fetches the pull request's head (as the server has it now) first and checks out the branch:
   • Only behind the pull request: brought up to the pull request's head first.
   • With commits of its own and behind (it has commits the pull request doesn't, and lacks some of the pull request's): Revue says how many and asks:
     • Rebase onto the pull request puts its commits on top of the pull request's head. If they conflict, the rebase is undone, the branch is left as it was, no worktree is created, and Revue says which files conflict.
     • Keep my branch checks it out as it is, out of date, for you to update.
     • Discard N commits moves it to the pull request's head; the commits stay in git's reflog for a while.
   • Already has all of the pull request (only commits of its own on top): checked out as it is.
   • Offline: checked out as it is.
   • Checked out in another folder: that worktree is used instead, and brought up to date when you open it (see New pushes to the pull request).
2. Otherwise, fetches the branch from the repository's remote (into refs/remotes/<remote>/<branch>). If its tip is the pull request's head commit, Revue creates a local branch that tracks it (git worktree add --track -b <branch>).
3. Otherwise (a pull request from a fork, or a branch that moved), fetches the pull request's head from where the service keeps it, then creates the branch from it:
   • GitHub, Forgejo, Codeberg, Gitea: refs/pull/<number>/head from the base repository's remote.
   • Bitbucket Cloud: the branch from the fork itself, at your remote's address with the fork's name in place of the repository's. Without the fork's name, it fails with Couldn't fetch from ; Bitbucket has no pull request refs for forks.

A branch made from a fork's pull request doesn't track a remote branch.

Revue marks the worktrees it creates with a small revue file in the worktree's admin folder (.git/worktrees/<name>/revue), holding revue: owner/repo#<number>. That's how it knows which ones it may list and delete. Deleting runs git worktree remove --force, which also removes that file.

Git runs with GIT_TERMINAL_PROMPT=0, so a fetch that needs a password fails instead of waiting.

Advanced: the Code tab's checkouts from your clone

With a clone set, the Code tab and the open buttons check out the commit they need as a detached worktree of your clone, inside Revue's cache (git worktree add --detach), fetching the commit first if your clone lacks it. Only FETCH_HEAD changes in your clone. These are marked revue-source: and aren't listed under Worktrees created by Revue. They're deleted in the background (through git, so your clone forgets them and your git tools stop listing them):

• when Revue sees the pull request merged or closed,
• when you close the pull request's tab,
• when one hasn't been used for 7 days (Revue looks when it starts, then every 6 hours),
• when it's no longer among the 3 most recent,
• or when you clear Source checkouts in Settings → Storage.

A checkout an open Code tab shows is never deleted. Checkouts of commits browsed in a repository's history go only after 7 days unused or past the 3 most recent. Anything changed in a checkout is lost when it's deleted. Downloaded copies (without a clone) only go past the 3 most recent or when you clear the cache.

When one of your own worktrees has the branch checked out, the Code tab reads the commit's files from it without writing anything to it. See Browsing code.

Choosing your default apps#

Revue finds the editors, terminals and AI assistants installed on your computer when it starts. Set which one each button uses in Settings → Apps → Default apps:

Each one is a menu of the apps found, with Automatic at the top. Picking an app from a header button's arrow menu changes this setting too.

If no editor is found, the editor button's tooltip says No editor found, and clicking it shows No code editor found. Set a custom editor command in Settings → Apps. The terminal button says No terminal found. The AI assistant button is hidden until an assistant is found.

A custom editor#

Not in the list? Add any editor under Custom editor in the same card:

1. Type the editor's program in Custom editor, or click Choose… to pick it.
2. Optionally add Arguments, such as --new-window. Write %f where the folder should go. Without %f, the folder goes last.
3. It now shows first in the editor list as Custom editor.

A program name on your PATH (such as helix) is enough. On macOS you can pick an .app bundle and Revue opens it with open -a. Clear the field to remove the custom editor.

Advanced: where these settings are kept

The choices are saved as editor, terminal and assistant (the app's id, or nothing for Automatic) and the custom editor as editor_command in Revue's settings. Use the card's Shared / This computer switch to keep them on one computer only. editor_command is left out of settings exports. See Settings reference and Files, sync and settings for one computer.

Editors Revue finds#

On Linux Revue lists every installed app that calls itself a text editor or IDE, so any editor with a desktop entry shows up. On macOS and Windows it looks for the editors below.

The table's order is the order in the menu, and the first one found is the default. On Linux, editors not in the table follow alphabetically.

Terminal editors such as Neovim and Vim open inside your default terminal, started in the folder (with the Code tab's file, if any).

Advanced: how editors are found and started, per system

Linux

• Revue reads the desktop entries (.desktop files) in $XDG_DATA_HOME/applications (or ~/.local/share/applications), the folders in $XDG_DATA_DIRS (or /usr/local/share and /usr/share), Flatpak's /var/lib/flatpak/exports/share and Snap's /var/lib/snapd/desktop.
• An entry is an editor when its categories include TextEditor or IDE, or Development for one of the known programs above. Entries that are hidden (Hidden, NoDisplay), whose TryExec or program isn't installed, or that are game engines (Godot, Unity, Unreal) are left out.
• Icons come from your icon themes.
• Revue runs the entry's Exec line with the folder (and the file, if any) in place of %f/%F/%u/%U, or added at the end. Entries marked Terminal=true run inside your default terminal.

macOS

• Revue looks for app bundles whose name starts with an editor's name in /Applications, /Applications/Utilities, /System/Applications/Utilities, ~/Applications and ~/Applications/JetBrains Toolbox.
• It starts them with open -a <app> <folder> [file]. Icons are converted from the bundle's .icns with sips and cached.

Windows

• Revue looks in %LOCALAPPDATA%\Programs, %ProgramFiles%, %ProgramW6432%, %ProgramFiles(x86)% and Scoop's apps folders (%SCOOP% or ~\scoop, and %SCOOP_GLOBAL%). It also looks in the folders the registry's uninstall entries and App Paths name (so installs on another drive are found) and on your PATH (code, cursor, subl…).
• JetBrains IDEs are found in JetBrains\<IDE>\bin\<ide>64.exe, Toolbox's install folders (the newest build) and its scripts\<ide>.cmd. Visual Studio is found in Microsoft Visual Studio\<version>\<edition>\Common7\IDE\devenv.exe. Neovim in Neovim\bin\nvim.exe or on PATH.
• Revue starts the editor's program with the folder (and the file) as arguments. Icons are extracted from the .exe with PowerShell and cached.

Terminals Revue finds#

The order is the menu's order. Automatic picks $TERMINAL or (on Linux) KDE's configured terminal first, then the first one found.

Advanced: how terminals are found and started in the folder

• Linux: desktop entries with the TerminalEmulator category, from the same folders as editors. Revue starts the terminal with its own working-folder option:

  Terminal	Started with	Runs a command after
  Ghostty, Xfce Terminal, Tilix, Terminator	--working-directory=<folder>	-e
  GNOME Terminal, Console (kgx), Ptyxis, MATE Terminal	--working-directory=<folder>	--
  foot	--working-directory=<folder>	(directly)
  Konsole	--workdir <folder>	-e
  kitty	--directory <folder>	(directly)
  Alacritty	--working-directory <folder>	-e
  WezTerm	start --cwd <folder>	--
  Others (xterm…)	started in the folder	-e

  Ghostty's --gtk-single-instance option is dropped, so a new window opens in the right folder.

• macOS: app bundles named Ghostty, iTerm, WezTerm, kitty, Alacritty, Warp, Hyper or Terminal, in the same folders as editors. Revue runs open -a <terminal> <folder>, adding --args <command> to run an assistant.

• Windows: wt, pwsh, powershell and cmd on your PATH. Windows Terminal starts with -d <folder>. PowerShell starts with -NoExit (and -Command to run an assistant). Command Prompt uses /K. Console programs get a window of their own.

AI assistants Revue finds#

The AI assistant button starts a command-line AI assistant in the folder, inside your default terminal, ready for you to type your request. It looks for these, on every system:

The first one found is the default. The button's tooltip says exactly what runs, for example Start Claude Code in the worktree …: runs claude in zsh, in Ghostty. The terminal window closes when the assistant exits.

Desktop chat apps (such as the Claude or ChatGPT apps) aren't listed: they can't be opened at a folder.

Advanced: how assistants are found and started

• Linux and macOS: Revue asks your login shell ($SHELL, else your account's login shell, else sh) which of the commands it can run, with <shell> -l -i -c. So aliases, shell functions and PATH changes in your shell's startup files count. fish is supported. If your shell doesn't answer within 10 seconds, Revue looks on its PATH and in the folders below instead.
• Windows: Revue looks on PATH (.exe, .cmd, .bat, .com) and in the folders below.
• Folders searched besides PATH: ~/.local/bin, ~/.claude/local, ~/.npm-global/bin, ~/.bun/bin, ~/.volta/bin, ~/.cargo/bin, ~/AppData/Roaming/npm, /opt/homebrew/bin and /usr/local/bin.
• Starting: Linux and macOS run <your shell> -l -i -c <command> in the terminal, so your aliases and functions apply. When the assistant was found only by its path, Revue runs it by name if your shell knows the name, else by its full path. Windows runs cmd /C <command> (npm installs .cmd launchers that only cmd runs).
• Revue passes no arguments or prompt to the assistant.

Opening a repository in your tools#

A repository's page (Repositories → a repository) has the same editor, terminal, AI assistant and folder buttons in its header.

• With a local clone set: they open your clone's folder as it is, whatever branch you have checked out there.
• Without one: they open the source at the commit on screen, downloaded first if needed (a progress circle shows in the header). If nothing has loaded yet, Revue says Nothing loaded to open yet.

On the repository's Code tab, the file you're viewing opens in the editor too.

Guide: Check a pull request out and run it#

1. Set a local clone of the repository (see Guide: Use an existing clone), or clone it from the Repositories page.
2. Open the pull request.
3. Click Create worktree in the header, then Create worktree in the bubble.
4. Wait for Worktree created in … and the green branch chip.
5. Click the terminal button. A terminal opens in the worktree, on the pull request's branch.
6. Install, build and run the project there as you normally would.
7. When the author pushes again, click the terminal button again: Revue pulls the new commits into the worktree first (your own commits on top).
8. When you're done, delete the worktree in Settings → the repository → Local clone → Worktrees created by Revue. Once the pull request is merged or closed, Revue offers to delete it for you.

Guide: Open a pull request in your editor#

1. Open the pull request.
2. Optional: open the Code tab and pick a file, so the editor shows it too.
3. Click the editor button in the header.
4. To use another editor, click the arrow beside the button and pick it. It becomes your default.

Without a clone set, the first click downloads the source (watch the progress circle), then the editor opens. Later clicks open it right away.

Guide: Hand a pull request to an AI assistant in a terminal#

1. Install a command-line assistant, such as Claude Code (claude) or Codex CLI (codex), and restart Revue.
2. Optional: pick it in Settings → Apps → Default apps → AI assistant, and your terminal under Terminal.
3. Open the pull request. For changes the assistant can commit, click Create worktree first.
4. Hover the AI assistant button to check what runs, for example runs claude in zsh, in Ghostty.
5. Click the AI assistant button. Your terminal opens in the pull request's folder with the assistant running.
6. Type your request, for example "Review this branch against main and run the tests".

Guide: Use an existing clone#

1. Open Settings and pick the repository under Repositories in the sidebar. (Or click the gear on the repository's page, or the yellow warning icon in a pull request's header.)
2. In the Local clone card, click Detect, or click Choose… and pick your clone's folder.
3. Check for the green Git clone of owner/repo (remote …) message.
4. Open a pull request of that repository. The header now shows Create worktree, or the green chip if you already have the branch checked out somewhere.

To set clones for many repositories at once, click Detect clones for all in the Settings sidebar, untick any you don't want, and click Apply.

Troubleshooting#

The editor or terminal I installed isn't in the list

• Restart Revue: apps are detected once, at start.
• Linux: the app needs a desktop entry with the TextEditor or IDE category (editors) or TerminalEmulator (terminals), and its program must be installed.
• macOS and Windows: only the editors and terminals in the tables above are found. Use Custom editor in Settings → Apps for any other editor.

My AI assistant isn't found

• Check that its command runs in a new terminal (claude --version, for example).
• Restart Revue after installing it.
• If your shell's startup files wait for input, the check times out after 10 seconds. Revue then only finds the assistant on PATH or in the usual install folders.

There's a yellow warning icon instead of "Create worktree"

Its tooltip explains it:

• No local clone of owner/repo is set, …: set one (click the icon to go to its settings).
• isn't a git clone of owner/repo. …: the folder is missing, isn't a git repository, or has no remote for this repository on this service.

Creating a worktree or checking out fails

• Couldn't create the worktree: … or Couldn't fetch commit … from …: git couldn't fetch. Check that git fetch works in your clone without a password prompt (Revue never shows one).
• On Bitbucket Cloud, a fork's pull request needs your sign-in to be able to read the fork.
• In the Code tab, Download the source instead downloads that one commit from the service when your clone can't provide it.