but resolve finish fails with 'No default target branch set' while on gitbutler/edit

[galligan]

Summary

but resolve finish (and but resolve status) fail with "Setup required: No default target branch set" while on the gitbutler/edit branch, even though the default target is correctly configured in virtual_branches.toml.

The gitbutler/edit branch is the one that but resolve <commit> itself checks out — so the user is put into a state where the resolve workflow cannot be completed through normal means.

Version

• but 0.19.0 (latest as of 2026-02-08)
• macOS (Darwin 25.3.0)

Steps to Reproduce

1. Have a GitButler workspace with a stacked branch that has a conflicted commit (e.g. after but absorb triggers a rebase conflict)
2. Enter conflict resolution: but resolve <conflicted-commit-sha>
   • GitButler checks out gitbutler/edit as expected
   • edit_mode_metadata.toml is written with the commit and stack IDs
3. Resolve the conflict in the working tree
4. Stage the resolved file: git add <file>
5. Run but resolve finish

Expected: Conflict resolution completes, workspace is updated with the resolved commit, returns to gitbutler/workspace

Actual:

Error: Setup required: No default target branch set.

Key Detail: the gitbutler/edit branch context

The error occurs specifically while on the gitbutler/edit branch — the branch that but resolve itself creates and checks out. This means the resolve workflow is broken end-to-end: but resolve puts you on gitbutler/edit, but but resolve finish cannot operate from that branch.

The virtual_branches.toml has the target correctly configured:

[default_target]
branchName = "main"
remoteName = "origin"
remoteUrl = "git@github.com:example/repo.git"
sha = "e95b8d100bc1f39cf25a6fc9c3fcfcb3c1850c37"
pushRemoteName = "origin"

Other commands like but setup read this target fine when run from gitbutler/workspace or main. The resolve subcommand's target lookup appears to use a different codepath that fails when the current branch is gitbutler/edit.

but resolve status also fails with the identical error, suggesting the issue is in the resolve subcommand's shared target resolution logic rather than being specific to finish.

Impact

This effectively makes conflict resolution impossible through the normal but resolve workflow. The user is stranded on gitbutler/edit with no way to complete the resolution via but commands.

Workaround

We were able to work around this by:

1. Manually creating a replacement git commit object (same tree from the "ours" side of the conflict, same parent/headers, but without the gitbutler-conflicted 1 header)
2. Using git replace <conflicted-sha> <clean-sha> so GitButler transparently sees the clean commit
3. Restoring the original virtual_branches.toml with the original commit SHAs
4. Running but teardown + but setup to rebuild the workspace

This required significant git plumbing knowledge and is not a realistic path for most users.

Environment

$ but --version
but 0.19.0

$ but update check
✓ You're running the latest version (0.19.0)

$ uname -a
Darwin 25.3.0

[Byron]

Thanks a lot for reporting.

This is indeed expected to work, and I think @schacon has most context to decide what a fix could look like.