GB fails silently when a change would get locked to two different vbranches

[daniilS]

Version

0.12.5

Operating System

Windows

Distribution Method

msi (Windows)

Describe the issue

When a change is made, and the resulting hunk overlaps with the context lines of hunks from two different lanes, gb stops processing new changes altogether without showing an error.

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. Make two changes to the file, and commit each to a different local vbranch:

Example screenshot:

3. Make a change between the two changes, big enough for the hunk to overlap (either directly, or only through context lines) with both previous changes. Save the file.

example.txt

1change in vbranch 1
2
3
4
5
6this will overlap with
7both vbranches
8
9
10change in vbranch 2
11
12
13
14
15
16
17
18
19
20

The change does not appear in gitbutler. If you make any other unrelated changes (e.g. in line 20), they won't appear either. If you close and reopen gitbutler, it will give a "Something went wrong..." black screen.

Screenshot:

Expected behavior

The proper way of handing this probably requires implementing hunk splitting, so until that's added, gb should fail gracefully and display an error to the user.

Temporary workarounds could include a button offering to combine all problematic lanes into one, or to unapplying all but one of the problematic lanes, but neither of those feel particularly satisfying.

Relevant log output

No response

[Byron]

Thanks so much for taking the time to make this issue easily reproducible! I also managed to follow along and end up in the same situation.

The developer version yielded the following output:

2024-06-20T19:56:49.558060Z ERROR handle: crates/gitbutler-watcher/src/handler.rs:54: error=failed to handle git file change event

Caused by:
    0: failed to list virtual branches
    1: failed to apply

I think @krlvi was looking for a way to reproduce this if I am not mistaken, and maybe this is what we needed to fix the issue once and for all.

[daniilS]

I've interestingly also started getting the "failed to apply" error sometimes when applying a branch that should simply resolve in a merge conflict - after unapplying and reapplying other vbranches, it seems to have gone away this time, so I'm not sure how to reproduce it, but maybe addressing this could also fix that in the process.

[daniilS]

Pretty sure this is closed by #4399