lazygit
lazygit copied to clipboard
lazygit appears to lock the currently-viewed file (at least on Windows)
Describe the bug I've noticed that if I leave lazygit running and the file I'm working on happens to be selected in the changes pane, then I can't save to the file (Rider complains that it can't update the file). Changing the selected file or closing down lazygit resolves the issue. I think this has only started happening recently (read: over the last month or two - sorry, I was off for most of December!)
To Reproduce Steps to reproduce the behavior:
- change a file, so it shows up in lazygit
- open lazygit, select the changed file
- alter & attempt to save the file from within IDE
- IDE shows error
Expected behavior I expect that lazygit will not lock up files
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):
- OS: Windows
- Lazygit Version 0.31.4
(this becomes a "close lazygit to continue" problem if there's only one file with diffs)
hmm I not sure what would be causing this. Lazygit just runs git diff on the file and I'd be surprised if that meant that it was locked.
ok, so if i git diff on the file in a terminal, I get the diff paged through less (afaik) - but this doesn't lock the file.
If I open up python and do:
import subprocess
p = subprocess.Popen(["git", "diff", "TemplateController.cs"], stdout=subprocess.PIPE)
then I replicate the same locking behavior - so it would seem to me that lazygit is doing something similar: reading from stdout from the git diff command and perhaps not closing the handle? Or perhaps not finishing reading from the process' stdout? In Python, if I add:
p.communicate()
to the above, then the lock is lost - I can write to the file again. I didn't have to p.terminate() or p.kill() (and doing so before the communicate() doesn't help) - so I'm assuming that since there's nothing left to write out to stdout, git diff is quitting all by itself. It would kind of make sense for git to lock the file whilst reading line-for-line: better for big files, where it can do output per changed line, I assume?
I have to assume that when paging, git is able to output everything and release the file lock - though the git process is still running:

Perhaps I should go looking through the source again (:
Feel free! That's some great investigation
I haven't looked yet, but I've also just (fascinatingly) not had a lock-up on a particular file which is selected, so I'm really curious to know at which point the file gets locked / released 🤔
One thing I've had is seeing that the .git/index.lock file is set such that I need to go in and delete it myself. Maybe happens once a fortnight. Could be related
update: I haven't seen this in a while and I haven't had a chance to investigate further ):
I do experience this as well quite often. Also with the Rider IDE, don't know if that causes the issue
I experience this Issue since 0.40.2. Can be reproduced (Windows 11, editing with Jetbrains Rider)
I also run into this issue constantly using LazyGit in my VSCode instanced PowerShell or even just in PowerShell standalone
I experience this issue as well with obsidian and neovim with lazygit