On Fri, Mar 22, 2013 at 12:14:27PM +0100, Johannes Sixt wrote:
> 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.
So shouldn't we be running all of the tests with both --symlinks and
--no-symlinks (except those which explicitly check that these options do
the right thing)?
> 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.
I fired up strace and it looks like difftool sees it as a working tree
file (i.e. the working tree content matches the RHS of the diff) in the
output of "git diff --raw --no-abbrev -z branch" and copies it over to
the temporary directories. Then when difftool completes it copies back
the working tree files from there.
When the file is copied to the temporary directory, the diff command
hasn't yet run so "output" is empty. When it's copied back it is after
the "ls" has run and so we overwrite the output of the command with the
original empty file.
So sticking the output file under .git does solve this issue since it
then is not treated as a working tree file.
Whether the current behaviour of difftool is entirely sensible is a
different question. I think we should at the very least by refusing to
overwrite working tree files that have been modified since they were
copied to the temporary directory
If I ever end up on a system using --no-symlinks I can see myself being
bitten by this by editing the original working tree file while
inspecting the diff in a separate window. I suspect this is just as
common a workflow as people editing the file in their diff tool and
wanting the changes copied back to the working tree.
John
--
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