Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > From: Ben Wijen <ben@xxxxxxxxx> > > On Windows, files cannot be removed unless all file handles to it have s/files/a file/, as the file handles later in the sentence are open on that single file. Alternatively s/file handles to it/file handles to them/. > 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@xxxxxxxxx> > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > --- Otherwise, nicely done. Thanks. > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html