Has anyone seen the ABL LS cause a git checkout to misbehave?

[PeterJudgeZA]

I'm seeing some strange behaviour at a site, and I suspect that the LS is somehow involved. There's a multiroot workspace with 5 or 6 projects in it, all from a single Git repo. VSCode is running on the latest prerelease. OE is 12.8 if that's relevant.

When changing branches and pulling from the origin, Git will regularly raise errors, leaving the worktree is a dirty state. Dirty here means there are incoming changes that are marked as changes, not integrated as they should be.

I've seen this when changing branches from within VSCode and when using an external tool. Not sure if it happens with the CLI Git client.

Example error from Git is below (oddly-enough the ITableModel.cls file often appears in the error list).

$ git checkout Train

error: unable to unlink old 'SmartComponentLibrary/Consultingwerk/OERA/ITableModel.cls': Invalid argument
error: unable to unlink old 'SmartComponentLibrary/Consultingwerk/SmartComponents/Base/SmartUiControlHandlerBase.cls': Invalid argument
M	SmartComponentLibrary/Consultingwerk/OERA/ITableModel.cls
M	SmartComponentLibrary/Consultingwerk/SmartComponents/Base/SmartUiControlHandlerBase.cls
Your branch is up to date with 'origin/Train'.
Switched to branch 'Train'

After this the listed programs are marked as modified via git status (and other tools).

I do not see this behaviour when VSCode is shut down, nor when VSCode is running and the ABL LS is stopped. I see the errors even when the LS says it has 0 tasks outstanding (I can see how the LS trying to compile a thing and Git trying to update a thing at the same time could cause issues). The files in question are not always open in VSCode (certainly not in the example above).

Has anyone else seen this? Am I doing something wrong here? I'm somewhat looking at the LS but it could also be the prowin or _progres client in all fairness.

[gquerret]

I may have spotted something, I'll work with Progress on that and keep you posted.