Skip to content

Limitations

Usage of git-spice with GitHub, GitLab, Bitbucket Cloud, Bitbucket Data Center / Server, Gitea, and Forgejo runs into limitations of what is possible on those platforms, and how they handle Git commits. Some limitations imposed on git-spice are listed below.

Write access required for stacked CRs

When a branch F is stacked on another branch B, and you want to submit Change Requests for both, the CR for F will be created against B. To do this, git-spice needs to push both branches to the same repository.

Therefore, to use git-spice to stack PRs, you need write access to the repository: specifically the ability to push new branches.

Fork mode submits only trunk-based branches

v0.28.0

When the upstream and push remotes differ, git-spice uses fork mode. In this mode, branch pushes go to the push remote, and Change Requests are opened against the upstream remote.

Fork mode creates Change Requests only for branches that are based directly on trunk. Branches stacked on top of another local branch are still pushed to the push remote, but stack submission commands skip Change Request creation for them.

To submit a fully stacked series of Change Requests, push access to the upstream repository is still required.

GitHub App authentication is incompatible with Fork mode. Use one of the other GitHub authentication methods instead.

Squash-merges restack the upstack

On GitHub, when a Pull Request is squash-merged into the trunk branch, all commits in that PR are replaced with a single commit with a different hash. Similarly on GitLab, when fast-forward merges are enabled, and commits are squashed, the commits in the MR are replaced with a single commit with a different hash.

The branches upstack from that CR are not aware of this new commit, still referring to the old, unsquashed history of the branch. GitHub and GitLab do not yet know to reconcile this new commit with the upstack branches, even though the contents are the same.

A B C D E main feat1 feat2 A B CD C D E main feat2 A B CD E main feat2  squash-merge  restack

As a result of this, when a branch is squash-merged into the trunk branch, branches upstack from it need to be restacked, and all their CRs updated.

To restack all branches above deleted merged branches and then submit the current stack after a squash merge, you can run:

The experimental merge commands automate this merge, sync, restack, and update loop. See Merging stacks.

Bitbucket Cloud limitations

v0.25.0

Bitbucket Cloud support has some limitations compared to GitHub and GitLab:

  • No PR labels: Bitbucket does not support pull request labels. The --label flag is ignored.
  • No PR assignees: Bitbucket does not support pull request assignees. The --assign flag is ignored.
  • Fixed pull request template paths: Bitbucket does not provide an API to list pull request templates, so git-spice reads them from a fixed set of well-known paths on the default branch: PULL_REQUEST_TEMPLATE.md or pull_request_template.md, at the repository root or inside a .bitbucket directory.

These are platform limitations, not git-spice limitations.

Bitbucket Data Center / Server limitations

v0.31.0

Self-hosted Bitbucket Data Center / Server support has some limitations compared to GitHub and GitLab:

  • No PR labels: Bitbucket Data Center does not support pull request labels. The --label flag is ignored.
  • No PR assignees: Bitbucket Data Center does not support pull request assignees. The --assign flag is ignored.
  • Draft PRs require Bitbucket Data Center 8.18+: On older servers the draft flag is ignored and a regular pull request is created.
  • Draft status cannot be toggled after creation: A pull request may be created as a draft, but Bitbucket Data Center does not allow changing its draft status afterward. The --draft and --ready flags are ignored when updating an existing PR.
  • No fork / cross-repository PRs: Pull requests are supported only between branches in the same repository.
  • Nested task counts require Bitbucket Data Center 7.2+: Comment resolution counts (shown by gs log --cr-comments) include tasks; on older servers, tasks left as replies within a comment thread are not counted.

These are platform limitations, not git-spice limitations.

Base branch change may dismiss approvals

Some remote repositories are configured to dismiss prior approvals of PRs when the base branch of that PR is changed. There is no workaround to this except to reconfigure the repository as this setting is fundamentally incompatible with a PR stacking workflow.