Skip to content

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

Draft
slarse wants to merge 1 commit into
masterfrom
GB-1294/branch-incorrectly-replaced
Draft

test(GB-1294): reproduce branch replace bug with test case#13912
slarse wants to merge 1 commit into
masterfrom
GB-1294/branch-incorrectly-replaced

Conversation

@slarse
Copy link
Copy Markdown
Contributor

@slarse slarse commented May 21, 2026

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 AI review requested due to automatic review settings May 21, 2026 08:02
@github-actions github-actions Bot added rust Pull requests that update Rust code CLI The command-line program `but` labels May 21, 2026
@slarse slarse marked this pull request as draft May 21, 2026 08:02
@slarse slarse requested a review from Caleb-T-Owens May 21, 2026 08:04
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +69 to +73
fn handles_adding_branch_anchored_on_branch_shared_by_other_stack() -> anyhow::Result<()> {
let env = Sandbox::init_scenario_with_target_and_default_settings("one-stack")?;
env.setup_metadata(&["A"])?;

env.but("branch new -a A first-stack").assert().success();
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duh...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLI The command-line program `but` rust Pull requests that update Rust code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants