Am 2/21/2013 5:03, schrieb David Aguilar:
> test_expect_success PERL 'difftool -d' '
> - diff=$(git difftool -d --extcmd ls branch) &&
> - echo "$diff" | stdin_contains sub &&
> - echo "$diff" | stdin_contains file
> + git difftool -d --extcmd ls branch >output &&
> + stdin_contains sub <output &&
> + stdin_contains file <output
> '
This test is broken on Windows. There is this code in git-difftool.perl
for my $file (@worktree) {
...
copy("$b/$file", "$workdir/$file") or
exit_cleanup($tmpdir, 1);
...
}
@worktree is populated with all files in the worktree. At this point,
"output" is among them. Then follows an attempt to copy a file over
"$workdir/$file". I guess that is some link+remove magic going on behind
the scenes. At any rate, this fails on Windows with
"D:/Src/mingw-git/t/trash directory.t7800-difftool/../../git-difftool line
408: Bad file number", because files that are open cannot be written from
outside (the file is open due to the redirection in the test snippet).
What is going on here? Why can this ever succeed even on Unix?
Same for some later tests.
BTW, while debugging this, I found the use of the helper function
stdin_contains() highly unhelpful; it just resolves to a 'grep' that on
top of all hides stdout. Please don't do that. Just use unadorned grep
like we do everywhere else.
-- Hannes
--
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