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
More majordomo info at

Reply via email to