test(GB-1294): reproduce branch replace bug with test case

[slarse]

Adds a test case to reproduce GB-1294.

The the problem appears when you have multiple stacks that share a branch applied at the same time, and you try to create a new branch anchored to the branch in one of those stacks.

I'm not entirely sure what semantics we even want to have here. @Caleb-T-Owens do you have any ideas? Before I dive further into this I think we should establish if this behavior is even supposed to be supported. But I think it feels sane to be able to have multiple stacks with a common base.

Example

For example, you may have this state:

$ but status
╭┄zz [unassigned changes] (no changes)
┊
┊╭┄se [second-stack]
┊●   187de8a second
┊│
┊├┄g0 [A]
┊●   9477ae7 add A
├╯
┊
┊╭┄fi [first-stack]
┊●   8673c86 first
┊│
┊├┄h0 [A]
┊●   9477ae7 add A
├╯
┊
┴ 0dc3733 (common base) 2000-01-02 add M
Hint: run `but help` for all commands

And then you'd want to add a new branch first-stack-middle anchored at h0.

but branch new first-stack-middle -a h0
✓ Created branch first-stack-middle stacked on A

I would expect the result to be that the branch is added to only one of the stacks, or possibly to both, but what actually happens is that A is replaced in the projection in both stacks.

$ but status
╭┄zz [unassigned changes] (no changes)
┊
┊╭┄se [second-stack]
┊●   187de8a second
┊│
┊├┄g0 [first-stack-middle]
┊●   9477ae7 add A
├╯
┊
┊╭┄fi [first-stack]
┊●   8673c86 first
┊│
┊├┄h0 [first-stack-middle]
┊●   9477ae7 add A
├╯
┊
┴ 0dc3733 (common base) 2000-01-02 add M
Hint: run `but help` for all commands

Funky variation

If you instead unapply e.g. second-stack and create a new branch anchored at A, then the branch is correctly inserted in the middle of first-stack. Applying second-stack afterwards leads to this (to me, expected) state:

╭┄zz [unassigned changes] (no changes)
┊
┊╭┄se [second-stack]
┊●   187de8a second
┊│
┊├┄g0 [A]
┊●   9477ae7 add A
├╯
┊
┊╭┄fi [first-stack]
┊●   8673c86 first
┊│
┊├┄h0 [first-stack-middle] (no commits)
┊│
┊├┄i0 [A]
┊●   9477ae7 add A
├╯
┊
┴ 0dc3733 (common base) 2000-01-02 add M

Hint: run `but help` for all commands

But if you then add a commit to first-stack-middle, then that branch and commit gets inserted into second-stack as well.

[Copilot]

Pull request overview

Adds a new Rust CLI test in the but crate intended to capture/regress GB-1294, where creating a new branch anchored on a branch shared by multiple applied stacks can incorrectly affect projections in other stacks.

Changes:

• Introduces a new integration test that sets up two stacks sharing branch A.
• Exercises but branch new -a <anchor> <new-branch> with an anchor (h0) that exists in one stack’s projection.
• Asserts the resulting but status output matches the intended “only mutate the targeted stack” behavior.

[slarse]

Duh...

[Byron]

This is on me, probably, at least if you can reproduce this in the tests for create_reference.

Can you give the reproduction there a shot?