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.