Teardown -> stack branch -> setup workflow supported?

[jonathantanmy2]

I was further looking into teardown/setup workflows. Is a workflow of teardown -> branch manipulation -> setup something that we want to support? If I teardown, put one branch on the other (with Git commands), and setup, I get branch A appearing 3 times in the status output.

╭┄zz [unstaged changes] 
┊     no changes
┊
┊╭┄g0 [A] (no commits) 
┊│
┊├┄h0 [A]  
┊●   9477ae721ab521d9d0174f70e804ce3ff9f6fb56 add A  
├╯
┊
┊╭┄i0 [B]  
┊●   f600f85 New commit on branch B (no changes)  
┊│
┊├┄j0 [A]  
┊●   9477ae721ab521d9d0174f70e804ce3ff9f6fb56 add A  
├╯
┊
┴ 0dc3733 (common base) [origin/main] 2000-01-02 add M 

Hint: run `but help` for all commands

I could take a look at this, but wanted to check first to make sure that I wasn't digging too much into an unsupported use case.

This is on origin/master. Stacking this on my other PR (#12085) gives the same result (except that there is no gitbutler/workspace branch after teardown).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
gitbutler-web	Ignored	Preview	Feb 3, 2026 5:28pm

[Byron]

Just wanted to drop by and add that I always refer to but-testing to take a look at the underlying data.
A blanked cargo run --bin but-testing -- -t -C /path/to/repo graph is useful to see the workspace projection actually, and there is also a cargo run --bin but-testing -- -t -C /path/to/repo ref-info to see the more processed version of that.

Maybe that helps to see what's really there, it would be a severe bug if there would be duplicate stacks like that.
If this is a test-repo you can easily zip up, I'd definitely also want to take a look.

[jonathantanmy2]

tsbs.tar.gz
I've attached the test repo that I generated using the commented out code in the PR. It's strange that the but CLI doesn't recognize it as a GitButler repository, though - or maybe GitButler repositories cannot be moved on disk.

$ pwd
/tmp/a
$ git status
On branch gitbutler/workspace
nothing to commit, working tree clean
$ but status|head
The current project is not configured to be managed by GitButler.

No GitButler project found at .

Please run `but setup` to switch to GitButler management.

Error: Setup required: No GitButler project found at .
$ ls .git
COMMIT_EDITMSG  config  description  gitbutler  HEAD  hooks  index  info  logs  objects  ORIG_HEAD  refs
$ ls .git/gitbutler
but.sqlite  operations-log.toml  virtual_branches.toml

[jonathantanmy2]

graph.txt
ref-info.txt
Output of the commands you mentioned. I'm not sure what exactly to look for there, but it seems to match what but status says.

Anyway it seems that from what you say, a commit shouldn't appear in 2 stacks like that, so I'll take a further look.

[Byron]

Thanks so much!

This is a bug, and fortunately it's not as terrible as it locks and thanks to the repro, I should be able to fix it tomorrow morning.

The problem here is that :3 has :5 set as related branch, which gives it a name when setting up the workspace. This is a feature gone wrong, and I hope to be able to limit or constrain it better.

If this wasn't buggy, it would have stack B with f600 and 9477, and stack A with 9477.

[jonathantanmy2]

If this wasn't buggy, it would have stack B with f600 and 9477, and stack A with 9477.

I think ideally we would have only one stack with two branches in it (one on top of the other), but I can take a look after you've sent your PR.

[Byron]

That's not possible, as the metadata says it must have two stacks (it's also displayed by but-testing graph).

  metadata: Some(
        Workspace {
            ref_info: RefInfo { created_at: "2023-01-31 14:55:57 +0000", updated_at: None },
            stacks: [
                WorkspaceStack {
                    id: 00000000-0000-0000-0000-000000000000,
                    branches: [
                        WorkspaceStackBranch {
                            ref_name: "refs/heads/A",
                            archived: false,
                        },
                    ],
                    workspacecommit_relation: Merged,
                },
                WorkspaceStack {
                    id: 00000000-0000-0000-0000-000000000001,
                    branches: [
                        WorkspaceStackBranch {
                            ref_name: "refs/heads/B",
                            archived: false,
                        },
                    ],
                    workspacecommit_relation: Merged,
                },
            ],
            target_ref: "refs/remotes/origin/main",
            target_commit_id: Sha1(0dc37334a458df421bf67ea806103bf5004845dd),
            push_remote: "origin",
        },
    ),

[jonathantanmy2]

Ah...that does make teardown then setup less useful.

[Byron]

Ah...that does make teardown then setup less useful.

That I don't understand, could you provide context?

[jonathantanmy2]

That I don't understand, could you provide context?

One thing that I've struggled to do in GitButler is more complex stack manipulation - e.g. I would like to be able to have a stack with 2 branches, the bottom one being only a test and the top one being production code, and toggle the top one "on" and "off" to ensure that the test fails without the production code and passes with the production code. We don't seem to be able to do such complex manipulations without the rebase engine understanding refs (well, it does now, but only to a limited extent), so I thought that teardown and setup would be a good "escape hatch" in the meantime, where I can teardown, do whatever ref manipulations I want using Git, and then setup back, so I was experimenting with some use cases. I already learned that creating a new branch doesn't work (the new branch is not incorporated by the gitbutler/workspace merge commit and does not appear in but status), and stacking 2 branches (this PR) was what I tried next (and it doesn't seem to work either, by design).

[Byron]

Ah, I see, thanks for sharing.

There is already a notion of re-merging a workspace commit without including portions of a stack, as measured from its tip. This would perfectly serve the case you describe.
Something that might already work is to apply the branch below the tip of the stack, and one can flip between them, applying lower, and then upper, while the new apply implementation will do the right thing, until we have a way to 'mute' portions of the stack from the top, without losing track of it.

[Byron]

Sorry for closing the PR like an issue 😅. If you rebase onto master, that particular issue will go away.