Changes keep jumping from my branch to the default branch

[TheYarin]

Version

0.12.25

Operating System

Windows

Distribution Method

msi (Windows)

Describe the issue

I constantly encounter the following bug: I drag changes from the default branch to another branch, and after a few seconds the changes jump back to the default branch. I drag them again, they move, and then after a few more seconds they jump back. I find myself having to quickly commit them before they jump back.

How to reproduce

Not sure, this happens often though

Expected behavior

well, I expect the changes to stay in the branch I put them in.

Relevant log output

No response

[Byron]

Thanks a lot for reporting!

It's sad to see the issue is so spurious. From a quick attempt I can say that it doesn't obviously reproduce - files dragged over to other virtual branches stay there, even when the app is refreshed either by hand or because the worktree changes.

Maybe you can find out what affects the issue, as it doesn't seem to always occur.

[TheYarin]

hmm, that sounds not so straight forward to pinpoint. is there any piece of code that might move changes from a virtual branch back to the default one? or maybe an operation that "resets" the state of GitButler?

I did notice a wider problem that takes form as many symptoms and might be related here, too: once an operation (such as moving changes between branches) starts, it captures (at least) the state of its original branch and if the operation takes a while and other operations are started in the meantime, they will effectively override any previous operations. Maybe this issue manifests here as well?

[Byron]

What a great idea!

Yes, the app is full of race conditions. However, by now we do queue them but maybe the function causing this isn't actually using this system. Typically I only added the system (i.e. a mutex) where a mutation was obvious and could use a long time.

CC @Caleb-T-Owens , as he might now better which mutating functions in the application aren't using the exclusive access lock, and are related to moving things between lanes?

[Caleb-T-Owens]

@Byron the move_commit_file is the one in question I believe. That said, most of the functions in virtual.rs ought to have the lock passed into them as well.

[Caleb-T-Owens]

@TheYarin Thanks for writing in.

I'll see if I can find some time this week to shore up our worktree write locks because that is unacceptable.

[Byron]

Thanks a lot @Caleb-T-Owens for chiming in!

This function definitely doesn't grab the lock to serialize it, which explains its raciness.

gitbutler/crates/gitbutler-branch-actions/src/actions.rs

Lines 291 to 292 in 7dbadb1

	vbranch::move_commit_file(&ctx, branch_id, from_commit_oid, to_commit_oid, ownership)
	.map_err(Into::into)

It will be quite some work to propagate it to all relevant places, but in return I'd expect all issues like these fixed.

On another note, it's interesting how serial the app has become, and that this is a good thing as that makes it deterministic as well. Taking this upon ourselves instead of just using non-async tauri commands seems beneficial overall as it helps differentiate mutating functions from read-only ones in an application that doesn't benefit from Rusts usual rules around mutation as all state lives on disk.

[TheYarin]

Glad to see you guys narrowed it down!

On another note, I had some suspicion this issue might be triggered by my IDE so I checked and can confirm this happens even when the IDE is closed.