aboutsummaryrefslogtreecommitdiff
path: root/lockfile.h
diff options
context:
space:
mode:
authorBen Wijen <ben@wijen.net>2016-08-18 16:51:12 +0200
committerJunio C Hamano <gitster@pobox.com>2016-08-18 13:56:45 -0700
commitad65f7e3b71aac841d771cd75392747d6945cc3c (patch)
treef84fee4fd2308c406b21e1eb07be5d14f341edde /lockfile.h
parente0c1ceafc5bece92d35773a75fff59497e1d9bd5 (diff)
downloadgit-ad65f7e3b71aac841d771cd75392747d6945cc3c.tar.gz
git-ad65f7e3b71aac841d771cd75392747d6945cc3c.tar.xz
t6026-merge-attr: child processes must not inherit index.lock handles
On Windows, a file cannot be removed unless all file handles to it have been released. Hence it is particularly important to close handles when spawning children (which would probably not even know that they hold on to those handles). The example chosen for this test is a custom merge driver that indeed has no idea that it blocks the deletion of index.lock. The full use case is a daemon that lives on after the merge, with subsequent invocations handing off to the daemon, thereby avoiding hefty start-up costs. We simulate this behavior by simply sleeping one second. Note that the test only fails on Windows, due to the file locking issue. Since we have no way to say "expect failure with MINGW, success otherwise", we simply skip this test on Windows for now. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'lockfile.h')
0 files changed, 0 insertions, 0 deletions