A locked hunk moves all other changes in the same file to the default branch

[daniilS]

Version

0.5.552

Operating System

Windows

Distribution Method

msi (Windows)

Describe the issue

When a new change is locked to a vbranch, it causes all previous changes in the same file to move to whatever the current default branch is.

How to reproduce

1. Create a file big enough for two changes to appear as different hunks.

example.txt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

2. Create three vbranches. Make a change somewhere in the file, and commit it to vbranch 1:

Example screenshot:

3. Make a separate change in vbranch 2, far enough from the previous change to not lock. Set vbranch 3 as the default branch.

Example screenshot:

4. Now, make a change close to the committed change in vbranch 1, so that it will lock to vbranch 1.
   
   Notice that the existing change unexpectedly moves from vbranch 2 to vbranch 3 (the default branch). If you now change the default branch, the not-locked change will immediately move there.

Example screenshot:

Expected behavior

A hunk locking should not affect the ownership of the other hunks in the same file. Changing the default branch should also not affect the ownership of existing hunks.

Relevant log output

No response

[Byron]

Thanks a lot for reporting, and for making the issue so straighforward to reproduce. When using Version 0.5.552 (20240621.032126), I could definitely reproduce the 'unlocked hunk is pulled to another vbranch', even though for me it was pulled to vbranch 1 together with the hunk that is close to the locked hunk (that was committed there).

The default branch (branch 3) didn't seem to contribute here. However, it might be me having not followed the reproduction steps precisely enough, or it's some other factor. What matters is that the unlocked unlocked hunk should probably not have been pulled over as well, at least it's surprising.

[daniilS]

@Byron in your screenshot, are the two changed lines the only changes that you made after the committed change?

If yes, then those form one hunk (because their context lines overlap), which is why they both get moved to the locked branch (until hunk splitting is supported). If you make the non-locking change far enough away to be in a separate hunk, then the non-locking change will get moved to the default branch, which is what my bug report is about.

If no, then can you show the two hunks corresponding to the two changes that you made in step 3 and 4 so I can try figure out what's different?

[Byron]

That's interesting - now that I tried again, I have a different result and one that I'd consider correct. However, I also had all the vbranches already with the default set to branch 3, maybe that affected it as well.

Additionally, maybe it's important to use the proposed file (I used an existing README), and to add changes exactly where you specify (i.e. line 1, 5, 10), for it to work reliably.

[mtsgrd]

I can reproduce this, take a quick look and see if I can find out what's going on.