Windows file lock interrupts git pull and leaves staging & workspace in an inconsistent state relative git index

The problem

Git desktop (and git bash) will leave the workspaces in an inconsistent state after failing to change a locked file. The user then is told they have a bunch files that they have changed both in untracked and “not staged for commit” The user gets confused because they didn’t have any changes prior to this and can panic into either deleting there work and making that delete into a new commit (destroying other peoples work) or adding/committing work that is already in the main branch.

Release version

3.0.3 x64

Operating system

Windows 10

Steps to reproduce the behavior

Our company hit this problem with a binary file (type: PDF) that was checked into the repo. It was NOT lfs tracked. The user had main branch of repo checked out and no changes in staging or working spaces. The user had “Adobe Reader DC” open and has that PDF file mentioned above open in the background. Another user changes unrelated files (.py, .csv, etc) in the same repo, commits & pushes those to main branch. Another user modifies the same PDF, commits/pushes to master…

The original user selects pull from Github desktop (they still have the PDF open in the background) Github desktop fails with an error that says… Unable to pull when changes are present on your branch. The following files would be overwritten

The user is now faced with a bunch of file changes they did not make. (upon careful inspection these “changed” files account for the other users commits. Yet they look like changes.

The user is still at there original commit point prior to doing a git pull. So they don’t see commits in their history, which makes sense as those commits are the reason for all the now modified files.

If you setup the same scenario above, but you use git bash you see this error and are prompted with y/n

 git pull origin main
From https://github.******
Unlink of file 'REDACTED/02REDACTED/REDACTED/REDACTED.pdf' failed. Should I try again? (y/n) y
Unlink of file 'REDACTED/02REDACTED/REDACTED/REDACTED.pdf' failed. Should I try again? (y/n) n
error: unable to unlink old 'REDACTED/02REDACTED/REDACTED/REDACTED.pdf.pdf': Invalid argument
Updating files: 100% (31/31), done.
Updating 120ea68..13eb04a

the outcome is the same when you do a git status with git bash. You see all the future commit changes in your workspaces (staged, working) as if you made changes to them.

Very confusing for users.

Log files

No response

Screenshots

No response

Additional context

No response

[alfred-stokespace]

Thanks @tidy-dev, an additional thought about how the product could behave better, would be to attempt a write locks on each file that github desktop knows is needing to be modified before making any file system changes. That way the user is not left with a chore upon failure.

An additional thought on your recovery steps, although I agree that in trivial cases one certainly can unlock, pull again, stash, discard stash this protocol gets much more complicated if the user had changes existing already before the pull and is ripe for confusion and error.

My user base consists largely of lower skill git users and these incidents are very confusing for them and quickly erode trust in git as a product ecosystem. Github Desktop seems targeted to initial git users. I’m faced with the possible admission that git and git tools are only suitable for experts. I really like git and want it to be more accessible to a broader audience so I really hope there is an improvement that can come out of this.

Thanks again for you response.

[tidy-dev]

@alfred-stokespace Thank you for reaching out! As you already recognized this behavior is not unique to GitHub Desktop and is the expected behavior of the underlying Git when there is a file that is locked that cannot be updated from an incoming pull.

The changes you are seeing are the remainder of the changes that would have been updated via commits if the pull had been successful. You can simply unlock the offending file (close the offending program). Then, hit pull again and it will ask you to stash and continue. It will stash those changes and the pull will succeed as expected. You should be free to discard that stash (or even discard those changes prior to pulling again).

That said, I am marking this ticket as a suggested enhancement. It would require investigation into under what scenarios does Git provide that “unable to link old file” error. Hopefully it would be possible to capture this error and display something more helpful about what to do when a user reaches this state. (maybe somethign along the lines of “The pull was unable to complete as X files were locked - likely open in another program (or other scenarios listed here). Please unlock the files, discard/stash the changes from the incomplete pull, and try again.”