Aborting merge leaves index.lock file

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start merging two branches
2. Press Abort
3. Note that you can no longer switch branches or do anything due to "fatal: 
Unable to create '****/.git/index.lock': File exists."

What is the expected output? What do you see instead?

What version of TortoiseGit and msysgit are you using? On
what operating system?

1.8.12
1.7.10
Win7

Please provide any additional information below.

Original issue reported on code.google.com by mik...@gmail.com on 5 May 2015 at 2:21

[GoogleCodeExporter]

We're just calling git.exe and if you abort git.exe on cli it is also likely 
that git.exe will leave the index.lock file.

TortoiseGit does not remove the file automatically as TortoiseGit does not know 
whether this was a bug in git.exe or any other git.exe instance is (still) 
running.

Sorry, but you have to delete *.lock files manually.

Dunno: Should we add a menu entry or dialog for cleaning theses files up (like 
TortoiseSVN cleanup)?

Original comment by sstrickr...@googlemail.com on 5 May 2015 at 4:30

• Changed state: WontFix

[GoogleCodeExporter]

If the user is pressing ABORT during a merge then it is fairly likely that the 
index.lock file is because of the ABORT. The merge cannot even start if the 
index.lock file is present beforehand. 

So the only situation that the lock file is not related to the aborted merge is 
if the merge finishes with the lock file, deletes it, then the user starts 
another git process before the merge finishes, presses abort on the merge 
process.. I think that is rare.

Whats the worst that can happen by removing the lock file?

At least I think TortoiseGit should detect the existence of the file after the 
abort and give me a button to clean it up, or give me a message saying I need 
to delete the file manually.

Alternatively, do nothing and when I get the next error message, give me an 
entry to say "please run cleanup or delete the lock file".

Original comment by mik...@gmail.com on 5 May 2015 at 5:13

[GoogleCodeExporter]

> Should we add a menu entry or dialog for cleaning theses files up (like 
TortoiseSVN cleanup)?

I think that is a good idea. :)
A friendly way to delete it, instead search + delete it.
(TortoiseGit -> Cleanup => adding one more option: Clean up working copy(tree) 
status)

The existence of index.lock means something wrong while updating that index 
file.
It is a sign, a warning. Perhaps the original index file is too old, too.
So, *automatically* deleting index.lock is not a good idea.

Should we need to delete index file and invoke "git reset" after deleting 
index.lock?

Original comment by yuelinho...@gmail.com on 6 May 2015 at 1:22

[GoogleCodeExporter]

Original comment by sstrickr...@googlemail.com on 7 May 2015 at 9:10

• Changed state: Discuss