Thread (27 messages) flat view 27 messages, 5 authors, 2016-06-15

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

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:56:28

Am 3/22/2013 11:00, schrieb John Keeping:
On Fri, Mar 22, 2013 at 08:13:46AM +0100, Johannes Sixt wrote:
quoted
Am 3/21/2013 8:41, schrieb Johannes Sixt:
quoted
Am 3/20/2013 23:59, schrieb David Aguilar:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help