index.lock always exists when using different worktree

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Create a git repository.
2.Edit its .git/config and set core.worktree to a different folder, such as 
../myrepo.
3.Go to the repo, do something and commit.

What is the expected output?

The commit should run normally.

What do you see instead?

I always get an error saying index.lock exists, although I am very sure there's 
only one tortoisegit process running.

Even though I remove the index.lock manually, the error still happens when I 
try to make the commit again.

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

TortoiseGit 1.8.9.0 / Windows 7 SP 1

Please provide any additional information below.

Original issue reported on code.google.com by danny0...@gmail.com on 16 Jul 2014 at 2:06

[GoogleCodeExporter]

Could you please provide simple repositories for testing?
Thank you.

Original comment by yuelinho...@gmail.com on 16 Jul 2014 at 5:25

[GoogleCodeExporter]

Here is a test pack. Cannot add bar.txt and commit it.

Original comment by danny0...@gmail.com on 16 Jul 2014 at 6:38

Attachments:

• tgit.7z

[GoogleCodeExporter]

Seems cause by "git update-index --refresh".

I tested both git.exe part and GitDLL part of CGit::RefreshGitIndex(), all of 
them create lock file and do not delete lock file.

Also tested on command line, "git update-index --refresh" does not delete lock 
file and does not show anything.

Trace code of tgit/compat/mingw.c
line 289 : xutftowcs_canonical_path() get the var wpathname 
"D:\testing\path\myrepo\.git\index.lock"
line 294 : _wunlink() should delete it.
line 295 : GetLastError() return 3(ERROR_PATH_NOT_FOUND)

the path is "D:\testing\path\myrepo\.git\index.lock"
should be   "D:\testing\path\myrepo.git\.git\index.lock"

I suppose it is git issue that xutftowcs_canonical_path() get wrong path.

Original comment by yuelinho...@gmail.com on 16 Jul 2014 at 9:36

[GoogleCodeExporter]

If the error is also in msysgit, please report it upstream.

Original comment by sstrickr...@googlemail.com on 16 Jul 2014 at 10:01

[GoogleCodeExporter]

Test cli again at D:\Repo\ 
Now, get the error:
fatal: Unable to write new index file

----
Test in Linux environment, the result:

vagrant@precise64:/vagrant/mytest/myrepo.git$ git --version
git version 2.0.0

vagrant@precise64:/vagrant/mytest/myrepo.git$ git update-index --refresh
fatal: Unable to write new index file

----
Report to 
http://git.661346.n2.nabble.com/git-update-index-not-delete-lock-file-when-using
-different-worktree-td7615300.html

Original comment by yuelinho...@gmail.com on 17 Jul 2014 at 3:23

[GoogleCodeExporter]

@sstrickroth
Does libgit2 support "git update-index --refresh"?
or Does libgit2 have a similar way to do that?

Original comment by yuelinho...@gmail.com on 17 Jul 2014 at 6:55

[GoogleCodeExporter]

@youlinho: There is a silimar way, however, it's not fully compatible.

Original comment by sstrickr...@googlemail.com on 25 Jul 2014 at 2:02

[GoogleCodeExporter]

Duy gives me a trial patch. It works for this issue, but he says:
"We could turn all lockfile's path absolute when setup_work_tree() 
moves pwd, but that seems dangerous without looking through how all 
lockfiles are used."

I see Duy is trying to fix it.
(http://git.661346.n2.nabble.com/PATCH-Make-locked-paths-absolute-when-current-d
irectory-is-changed-td7615398.html)

Original comment by yuelinho...@gmail.com on 25 Jul 2014 at 3:13

[GoogleCodeExporter]

Was a fix appied to upstream git?

Original comment by sstrickr...@googlemail.com on 30 Jul 2014 at 5:31

[GoogleCodeExporter]

Not yet. (checked in official git 2.0.4)

----

AFAIK, latest messages about the patches:

1. Junio C Hamano (Jul 22, 2014)
"OK, we should center these efforts around the strbuf_getcwd() topic, 
basing the other topic on realpath() and this one on it then?"

2. Duy Nguyen (Jul 23, 2014)
reply "OK"

Original comment by yuelinho...@gmail.com on 31 Jul 2014 at 3:01

[GoogleCodeExporter]

The root cause is using **relative** path to access index.lock file.
So, upstream(official git) try to use **absolute** path to access lock file, 
instead of relative path.

The following is old news(2014-08-01):

What's cooking in git.git (Aug 2014, #01; Fri, 1)
(http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Aug-2014-01-Fri-1-td7
616251.html)

Summarize as following:
-------------------------------------------------- 
...
-------------------------------------------------- 
[New Topics] 
...

* nd/lock-paths-absolute (2014-08-01) 3 commits
 - lockfile.c: store absolute path
 - lockfile.c: remove PATH_MAX limit in resolve_symlink()
 - lockfile.c: remove PATH_MAX limitation (except in resolve_symlink)
 (this branch uses rs/strbuf-getcwd.)

...
-------------------------------------------------- 
[Cooking] 
...

* rs/strbuf-getcwd (2014-07-29) 10 commits 
  (merged to 'next' on 2014-07-31 at 6edc3bc) 
 + use strbuf_add_absolute_path() to add absolute paths 
 + abspath: convert absolute_path() to strbuf 
 + use xgetcwd() to set $GIT_DIR 
 + use xgetcwd() to get the current directory or die 
 + wrapper: add xgetcwd() 
 + abspath: convert real_path_internal() to strbuf 
 + abspath: use strbuf_getcwd() to remember original working directory 
 + setup: convert setup_git_directory_gently_1 et al. to strbuf 
 + unix-sockets: use strbuf_getcwd() 
 + strbuf: add strbuf_getcwd() 
 (this branch is used by nd/lock-paths-absolute.) 

 Will cook in 'next'. 

...

Original comment by yuelinho...@gmail.com on 6 Aug 2014 at 3:28

[GoogleCodeExporter]

Original comment by sstrickr...@googlemail.com on 10 Aug 2014 at 2:23

• Changed state: ThirdPart

[GoogleCodeExporter]

News update:

What's cooking in git.git (Aug 2014, #03; Wed, 20)
(http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Aug-2014-03-Wed-20-td
7617178.html)

Summary:

--------------------------------------------------
[Cooking]

* nd/lock-paths-absolute (2014-08-01) 3 commits 
 - lockfile.c: store absolute path 
 - lockfile.c: remove PATH_MAX limit in resolve_symlink() 
 - lockfile.c: remove PATH_MAX limitation (except in resolve_symlink) 

 Will drop and ask Michael to possibly cooperate and merge with mh/lockfile. 

-------------------------------------------------- 
[Stalled] 

* mh/lockfile (2014-04-15) 25 commits 

[snip]

 Ejected from 'pu' to unclutter. 
 Expecting a reroll. 

Original comment by yuelinho...@gmail.com on 21 Aug 2014 at 1:47

[GoogleCodeExporter]

News Update:

Michael re-rolled mh/lockfile (v4), but it is not reviewed yet.
See:
http://thread.gmane.org/gmane.comp.version-control.git/256564

Also see:
What's cooking in git.git (Sep 2014, #02; Tue, 9)
http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Sep-2014-02-Tue-9-td76
18297.html

Then, Michael also gives another patch to fix this issue.
See:
http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Aug-2014-02-Fri-8-td76
16651.html#a7618171
http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Aug-2014-02-Fri-8-td76
16651.html#a7618172

Original comment by yuelinho...@gmail.com on 10 Sep 2014 at 2:45

[GoogleCodeExporter]

News update:

see: 
http://git.661346.n2.nabble.com/What-s-cooking-in-git-git-Nov-2014-02-Tue-11-td7
621005.html

Summary:

What's cooking in git.git (Nov 2014, #02; Tue, 11)
​--------------------------------------------------
[Cooking]

* nd/lockfile-absolute (2014-11-03) 1 commit
  (merged to 'next' on 2014-11-06 at 68722a9)
 + lockfile.c: stor​​e absolute path

 The lockfile API can get confused which file to clean up when the
 process moved the $cwd after creating a lockfile.

 Will cook in 'next' throughout the remainder of the cycle.

Original comment by yuelinho...@gmail.com on 12 Nov 2014 at 2:28

[GoogleCodeExporter]

News:

The fix has been merged into the master of vanilla git and it is included in 
the version v2.3.0-rc0.
(NOTE: not included in v2.2.2)

The fix is fa137f67a40bbcb3f583920586fdd34ce98ddeaf.
The mreging point is bb86a40e06ce1caafd74cc9fc87db4d5da8e3d07.

----
@csware
I suppose I am done for tracing the fix of upstream. :)

Please see CGit::RefreshGitIndex() first, then:

Should update gitdll and libgit project? 
(hard work!? it is so far between 1.9.0 and 2.3.0-rc)

or try to fix via applying the patch?
(I tried once, can't be applied directly, hit conflicts. And seems a bad idea.)

or just drop the part git_run_cmd() in CGit::RefreshGitIndex()?
(If not drop it, the status should not be "ThirdPart". Dropping will be the 
easy way. :P)

Original comment by yuelinho...@gmail.com on 14 Jan 2015 at 2:48

[GoogleCodeExporter]

about the fix of upstream, more ref:
the fix: 
https://github.com/git/git/commit/fa137f67a40bbcb3f583920586fdd34ce98ddeaf

Original comment by yuelinho...@gmail.com on 14 Jan 2015 at 2:51