Git process not ending.

[0x539]

Got to work this morning and Cmder asked me to update.

Since then it seems the git process does not end when you enter a directory setup as a repo.

This causes the following error when you try to commit:

C:\xampp\htdocs\SNIP (master)
λ git commit -m "added initial clean files"
fatal: Unable to create 'C:/xampp/htdocs/SNIP/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

I feel like the process is not ending as when you enter the directory the tabs at the bottom is still showing git.exe but I am able to type in the prompt:

http://imgur.com/a/x0YGi

You also get the incomplete operations confirmation dialog.

http://imgur.com/a/HIZOz

[hacst]

Also having this issue. Windows 7 with cmder 1.3.0 and a locally installed git for windows 2.9.2 64bit. It seems to launch another git process that gets stuck every time you hit enter (maybe the identification of the dirty state?). Unfortunately that made the release completely unusable to me and I had to go back to my 1.2.9 version which doesn't show this issue.

[Stanzilla]

@hacst @0x539 In vendor\clink.lua

line 206
for line in io.popen("git status --porcelain 2>nul"):lines() do
replace that with
for line in io.popen("git status 2>nul"):lines() do

does that help?

[hacst]

@Stanzilla Unfortunately that didn't help. If I apply your patch I still see the issue.

To elaborate on my earlier description: When launching cmder 1.3.0 two git.exe processes are being started and (apparently) never exit. Each press of enter launches two new ones which also don't exit. This effect only occurs when the cwd is a git repository. In both cases (launch and pressing enter) no git processes linger if it isn't.

[jankatins]

What happens when you run git status --porcelain in that dir (in a cmd window)?

Also, what happens if you change the function (in vendor\clink.lua) back to

function get_git_status()
     local file = io.popen("git diff --quiet --ignore-submodules HEAD 2>nul")
     -- This will get a table with some return stuff
     -- rc[3] will be the signal, 0 or 1
     local rc = {file:close()}
     return rc[3] == 0
 end

[I'm completely guessing here :-( ]

[0x539]

Sorry for taking a while.

@Stanzilla you're suggestion seems to have fixed the .lock issue for me. Thank you!

Just one minor thing it has caused is the branch display is now constantly red (as if I have modified files, even when branch is clean.)

http://imgur.com/a/hzzmp

[hacst]

Now this is interesting. I was wondering why I couldn't reproduce what I described yesterday no matter whether I had applied @Stanzilla 's suggestion or not. No lingering git.exe processes at all. Then it occured to me that in the meantime a .gitignore was added because of the excessive amount of untracked files. Guess what: Dropping that gives me back the symptoms. To get a feel about the amount, here how many lines come out of git status --porcelain:

>git status --porcelain | wc -l
282

The command takes around half a second or so and leaves no lingering git.exe when executed in a cmd.exe outside of cmder.

cmder behaves like I described yesterday. I also tried @JanSchulz 's replacement function but that didn't seem to change anything.

Restoring the .gitignore leaves me with two lines from git status --procelain and the two git.exe's only flash up very quickly in the task manager and vanish again instantly when working with cmder.

For me the branch also shows as changed in cmder even though git status tells me there are no changes.

[vBm]

I must say that i also experience this problem on one of the repositories. Reverting back the function (9c0ad9f) does fix the issue in my case.
Removing untracked junk files from the repo also fixes the issue. Adding those to .gitignore fixes too.

[arlinsandbulte]

I was having this issue too with cmder 1.3.0
Updating to 1.3.1 seems to have solved the issue for me.

[hacst]

@arlinsandbulte 1.3.1? From what I can tell there is no such thing yet. Are there snapshot versions of cmder or sth.?

[Stanzilla]

@hacst https://github.com/cmderdev/cmder/releases/tag/1.3.1

[arlinsandbulte]

I think the download link on cmder.net has not been updated yet. It still points to the 1.3.0 release.
But, the 1.3.1 release was tagged on gihub just a couple days ago by Stanzilla.

[Stanzilla]

Might be worth keeping in mind git-for-windows/git@01d1dd8

[hacst]

@Stanzilla ah. I see. I looked for the tag but because all previous ones had a "v" prefix (e.g. v1.3.0) 1.3.1 lacking that and being sorted to the bottom was unexpected.

[hacst]

I tried again with 1.3.1 today but the behavior hasn't changed. As soon as I have a repository with a sufficient amount of untracked files (by removing my .gitignore) two git.exe processes stick around and the .lock file is held open preventing me from most actions on the repository. Also I still get the branch name displayed as if the repository was dirty even if I restore the .gitignore and no git.exe's linger.

Here is a small reproducer repository: cmder-linger-test.zip . It consists of nothing but an initialized git repo (no commits) with ~2k untracked (empty) files. As soon as I enter the repository cmder displays it as dirty (which is incorrect) and I get the lingering git.exes. If you rename the TEST.gitignore in the folder to .gitignore you'll see that the repo is still displayed as dirty by cmder (still incorrect) but no git.exe s linger and you can at least perform actions on the repo. Hope that helps.

[churtado]

Having same problem, used the suggested fix to clink.lua but now git status shows the list of changes as if they haven't been commited.

[Morkowski]

I had the same problem. Unable to commit when many files were changed. Temporary solution was to commit changes from normal cmd. When list of modified files are small, everything works okay for me.

[churtado]

@Morkowski I just updated to the latest version and it's working again.

[Morkowski]

@churtado I noticed it today, after updating cmder.
But to be honest, I don't remember commiting so many files at the same time for the pretty long time. So I don't know when it broke.

[hacst]

So does the reproducer from my previous comment work for anyone else? As mentioned for me it still reproduced the issue with 1.3.1. I think it should at least allow to locate where the problem is coming from.

[vBm]

Tried with bb312ad, still doesn't help unfortunately.

Adding --quiet per previous comment does fix the issue at hand.

[alexandr-san4ez]

Sorry, I hurried.

[CameronFraser]

I still have the issue with 1.3.1 upgrade

[alexandr-san4ez]

@njoror try this - #1101

[CameronFraser]

@alexandr-san4ez Thanks! that worked

[reach4thelasers]

This bug has resurfaced with the latest version 161022

[alexandr-san4ez]

@reach4thelasers try this - #1101

[partharkl]

I am trying to commit the test file but it's not working.
Showing following error. I am using the latest version 2.10.2

"fatal: Unable to create 'C:/xampp/htdocs/GIT/test/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier"

Can anybody help ?

[alexandr-san4ez]

@partharkl. Have you tried the solution which I have indicated above?

[partharkl]

Yes. I have tried that also. showing the error command not found.

[alexandr-san4ez]

@partharkl try git version 2.10.0.1. I'm use this version.
I can throw a portable version. If your not found it.

[partharkl]

May be I was doing wrong.
Let me explain when I am getting this error.

I am just create a new text file test.txt and first commit to git. First time this one worked perfectly.
After that I have made changes one line and try to commit it to same test.txt file, but then the mention error shows up.

If this is the error due to 2.10.2 then kindly give me the link for working version.

[alexandr-san4ez]

Git-v2.10.0.1.7z

[partharkl]

Thanks @alexandr-san4ez
I will try this version.

[vhanla]

Tried with all your suggestions, no fix to .git/index.lock issue, I can only tell that in my case it shows that error when there is a lot of files added/modified

Cmder version: 161022

[seancheung]

Still happens when there is a lot of files added/modified.

Have to switch to PowerShell to commit and then come back.

[vertisan]

Same here.
I have a newest version - only in Cmder I can't do nothing because "index.lock: File exists"

[musartedev]

I deleted the index.lock file, but all the commits I hadn't push are gone. So, be careful when doing that.

[seancheung]

@musenberg404

I don't think it's possible.
It's just a lock file, not the index itself. So go ahead and delete it! LOL

Right click on the shell tab and choose Kill all but shell before doing the deletion.

[seancheung]

An approach to avoid this is to chain git commands:

git add . + git commit -m "commit" ==> git add . && git commit -m "commit"

so it won't happen.

[musartedev]

@seancheung Lol. You are absolutely right. The commits are there, I'm sorry.

Right click on the shell tab and choose Kill all but shell before doing the deletion.

Thanks! I'll try that next time.

[manjeetndps]

Use below command in root folder of your project . e.g D:/Selenium Git (master)

rm -f ./.git/index.lock

[Zarabozo]

I resolved this by replacing the function get_git_status in vendor\clink.lua for the following code - and I think it's actually making everything faster. I used to experiment some lag on each "enter" with large repositories, and now I'm not seeing that - though I still have to do more testing on that.

function get_git_status()
    local command = io.popen("git status --porcelain 2>nul")
    local is_clean = true
    for line in command:lines() do
        is_clean = false
        break
    end
    command:close()
    return is_clean
end

[Stanzilla]

Might get a real fix soon git-for-windows/msys2-runtime@78e2dee