git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <johannes.schindelin@gmx.de>
To: git@vger.kernel.org
Cc: Ben Wijen <ben@wijen.net>, Junio C Hamano <gitster@pobox.com>,
	Lars Schneider <larsxschneider@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: [PATCH v2 1/2] t6026-merge-attr: child processes must not inherit index.lock handles
Date: Thu, 18 Aug 2016 16:51:12 +0200 (CEST)	[thread overview]
Message-ID: <1678936297177e29db6253b09d75ec53ca6ad668.1471531799.git.johannes.schindelin@gmx.de> (raw)
In-Reply-To: <cover.1471531799.git.johannes.schindelin@gmx.de>

From: Ben Wijen <ben@wijen.net>

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>
---
 t/t6026-merge-attr.sh | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh
index ef0cbce..3d28c78 100755
--- a/t/t6026-merge-attr.sh
+++ b/t/t6026-merge-attr.sh
@@ -181,4 +181,17 @@ test_expect_success 'up-to-date merge without common ancestor' '
 	)
 '
 
+test_expect_success !MINGW 'custom merge does not lock index' '
+	git reset --hard anchor &&
+	write_script sleep-one-second.sh <<-\EOF &&
+		sleep 1 &
+	EOF
+
+	test_write_lines >.gitattributes \
+		"* merge=ours" "text merge=sleep-one-second" &&
+	test_config merge.ours.driver true &&
+	test_config merge.sleep-one-second.driver ./sleep-one-second.sh &&
+	git merge master
+'
+
 test_done
-- 
2.9.2.691.g78954f3



  reply	other threads:[~2016-08-19  6:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17 12:40 [PATCH 0/2] Do not lock temporary files via child processes on Windows Johannes Schindelin
2016-08-17 12:40 ` [PATCH 1/2] t6026-merge-attr: child processes must not inherit index.lock handles Johannes Schindelin
2016-08-17 17:55   ` Junio C Hamano
2016-08-17 12:41 ` [PATCH 2/2] mingw: ensure temporary file handles are not inherited by child processes Johannes Schindelin
2016-08-17 12:48   ` Eric Sunshine
2016-08-18 14:42     ` Johannes Schindelin
2016-08-17 13:14   ` Lars Schneider
2016-08-17 18:22   ` Junio C Hamano
2016-08-18 14:50     ` Johannes Schindelin
2016-08-18 17:35   ` Eric Wong
2016-08-18 21:53     ` Junio C Hamano
2016-08-18 22:48       ` Eric Wong
2016-08-19 15:57         ` Junio C Hamano
2016-08-22 12:47           ` Johannes Schindelin
2016-08-18 14:51 ` [PATCH v2 0/2] Do not lock temporary files via child processes on Windows Johannes Schindelin
2016-08-18 14:51   ` Johannes Schindelin [this message]
2016-08-18 14:51   ` [PATCH v2 2/2] mingw: ensure temporary file handles are not inherited by child processes Johannes Schindelin
2016-08-22 12:47   ` [PATCH v3 0/2] Do not lock temporary files via child processes on Windows Johannes Schindelin
2016-08-22 12:47     ` [PATCH v3 1/2] t6026-merge-attr: child processes must not inherit index.lock handles Johannes Schindelin
2016-08-22 12:47     ` [PATCH v3 2/2] mingw: ensure temporary file handles are not inherited by child processes Johannes Schindelin
2016-08-22 17:58       ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1678936297177e29db6253b09d75ec53ca6ad668.1471531799.git.johannes.schindelin@gmx.de \
    --to=johannes.schindelin@gmx.de \
    --cc=ben@wijen.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=larsxschneider@gmail.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).