Test integrate upstream with conflicting local branch

[mtsgrd]

The test integrate_upstream_with_conflicting_local_branch is located in crates/gitbutler-branch-actions/tests/virtual_branches/apply_virtual_branch.rs (line 558).

What it tests:

1. Sets up a scenario where:
   • Remote has commits A → B (B modifies file.txt)
   • Local base is at A
   • Local branch has commit C that also modifies file.txt(creating a conflict with B)
2. Verifies that upstream_integration_statuses returns BranchStatus::Conflicted { rebasable: false }
3. Performs integrate_upstream with merge strategy
4. Currently failing assertion: Expects the stack to have exactly 1 branch after integration, but it currently has 2 branches: ["conflicting-branch", "master"]

The test expresses your expectation that there should be only one branch in the stack after integration. The test is failing, which indicates there's a bug in the integration logic that's creating an extra "master" branch.

[vercel]

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

1 Skipped Deployment

Project	Deployment	Review	Updated (UTC)
gitbutler-web	Ignored	Preview	Jan 23, 2026 2:47pm

[mtsgrd]

I asked claude to help me understand why the test is failing and got this reasonable response:

After the merge integration, the commit graph looks like this:

                conflicting-branch (HEAD)
                       |
                       v
                [Merge Commit]
                  /         \
        (1st parent)      (2nd parent)
                /               \
               v                 v
[commit C - local change]    [commit B - remote change]  <-- origin/master
               |                 |
               v                 v
         [commit A - initial]----+
               |
               v
        [Initial commit]

The merge commit has two parents:

1. First parent: commit C (the local conflicting change) - this is the "main line" of the branch
2. Second parent: commit B (the remote change, i.e., origin/master) - this is the branch being merged into the current branch

What the graph traversal currently does:

When building stack segments, the traversal follows all parents. So it sees:

Segment 1: conflicting-branch → Merge Commit → commit C (following first parent)
Segment 2: master → commit B → commit A → Initial commit (following second parent from the merge)

What it should do:

For determining the stack structure (i.e., which branches belong to this stack), the traversal should only follow the first parent. The second parent represents the branch that was merged in, not a branch that's part of this stack.

In other words: master (the target branch / upstream) should not be considered part of the conflicting-branch stack just because we merged it into conflicting-branch. The merge commit's second parent points to origin/master, but that's external to the stack - it's the upstream we integrated, not a branch we own.

The fix should:

When building a stack's segments, recognize that commits reachable only via the second (or later) parent of a merge commit, where those commits belong to the target branch, should be excluded from the stack's segment list. They are "merged-in history", not "stack history".

[mtsgrd]

AI generated fix to added test also added as a second commit.

[Byron]

Thanks for tackling this!

I only glimpsed at it and believe this one will take some time to review, a test in but-graph that shows the issue to solve, and a proper implementation of the fix.
Meanwhile, let's be sure this doesn't get merged -I will try to get to it properly soon.

[mtsgrd]

Meanwhile, let's be sure this doesn't get merged

Ofc, I only put this up to demonstrate the problem ✌️

[Byron]

As getting into this could be a huge time-sink, I had to put it onto my backlog to be able to focus on unapply(). The only consolation I can give is that I let it jump the queue and put it first.

[mtsgrd]

No worries. I force pushed to this branch to remove that second commit, so this pr is now just adding a test that demonstrates the issue.