Subject: Re: [PATCH v3 3/4] t7800: modernize tests

From: Johannes Sixt <[email-masked]>
Date: Fri, 22 Mar 2013 12:14:27 +0100

Am 3/22/2013 11:00, schrieb John Keeping:
> On Fri, Mar 22, 2013 at 08:13:46AM +0100, Johannes Sixt wrote:
>> Am 3/21/2013 8:41, schrieb Johannes Sixt:
>>> Am 3/20/2013 23:59, schrieb David Aguilar:
>>>> I started digging in and the @worktree_files (aka @worktree above)
>>>> is populated from the output of "git diff --raw ...".
>>>>
>>>> Seeing the "output" filename in "diff --raw" implies that one of the
>>>> tests added "output" to the index somehow.  I do not see that
>>>> happening anywhere, though, so I do not know how it would end up in
>>>> the @worktree array if it is not reported by "diff --raw".
>>>>
>>>>
>>>> My current understanding of how it could possibly be open twice:
>>>>
>>>> 1. via the >output redirect
>>>> 2. via the copy() perl code which is fed by @worktree
>>>>
>>>> So I'm confused.  Why would we get different results on Windows?
>>>
>>> I tracked down the difference between Windows and Linux, and it is...
>>>
>>> 	for my $file (@worktree) {
>>> 		next if $symlinks && -l "$b/$file";
>>>
>>> ... this line in sub dir_diff. On Linux, we take the short-cut, but on
>>> Windows we proceed through the rest of the loop,
>>
>> And that is likely by design. From the docs:
>>
>> --symlinks
>> --no-symlinks
>>
>>     git difftool's default behavior is create symlinks to the working
>>     tree when run in --dir-diff mode.
>>
>>     Specifying `--no-symlinks` instructs 'git difftool' to create
>>     copies instead.  `--no-symlinks` is the default on Windows.
>>
>> And indeed, we have this initialization:
>>
>> 	my %opts = (
>> 		...
>> 		symlinks => $^O ne 'cygwin' &&
>> 				$^O ne 'MSWin32' && $^O ne 'msys',
>> 		...
>> 	);
>>
>> Can the --dir-diff tests case pass on Cygwin when neither --symlinks nor
>> --no-symlinks is passed?
>>
>> Perhaps the right solution is this:
> 
> We already have tests that explicitly pass '--symlinks'.  I wonder if it
> would be better to change "output" to ".git/output", which should avoid
> the problem by moving the output file out of the working tree.

The point of using --symlinks is not to test the effect of the option, but
to test the same thing on Unix and on Cygwin, because the latter uses
--no-symlinks by default. Therefore, I think that this sketch is the right
thing to do.

But the real problem seems to be that "output" should not be among the
files treated in the cited pieces of code (unless I'm wrong, of course; I
know next to nothing about git-difftool). It should not matter where the
file lives. Just add --no-symlinks to the difftool invocation of test
"difftool -d" and watch it fail on Linux, too.

-- Hannes