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

> 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.