On Fri, Mar 22, 2013 at 4:05 PM, John Keeping <john@xxxxxxxxxxxxx> wrote: > On Fri, Mar 22, 2013 at 03:53:38PM -0700, Junio C Hamano wrote: >> John Keeping <john@xxxxxxxxxxxxx> writes: >> >> > When 'git difftool --dir-diff' is using --no-symlinks (either explicitly >> > or implicitly because it's running on Windows), any working tree files >> > that have been copied to the temporary directory are copied back after >> > the difftool completes. This includes untracked files in the working >> > tree. >> >> Hmph. Why do we populate the temporary directory with a copy of an >> untracked path in the first place? I thought the point of dir-diff >> was to materialize only the relevant paths to two temporaries and >> compare these temporaries with a tool that knows how to compare two >> directories? >> >> Even if you had path F in HEAD that you are no longer tracking in >> the working tree, a normal >> >> $ git diff HEAD >> >> would report the path F to have been deleted, so I would imagine >> that the preimage side of the temporary directory should get a copy >> of HEAD:F at path F, while the postimage side of the temporary >> directory should not even have anything at path F, when dir-diff >> runs, no? >> >> Isn't that the real reason why the test fails? The path 'output' is >> not being tracked at any revision or in the index that is involved >> in the test, is it? > > Actually it is, which is what I missed earlier. > > A couple of tests before this 'setup change in subdirectory' does 'git > add .' which is far more general than it needs. Perhaps this is a > better change: > > diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh > index bba8a9d..561c993 100755 > --- a/t/t7800-difftool.sh > +++ b/t/t7800-difftool.sh > @@ -314,7 +314,7 @@ test_expect_success PERL 'setup change in subdirectory' ' > git commit -m "added sub/sub" && > echo test >>file && > echo test >>sub/sub && > - git add . && > + git add file sub/sub && > git commit -m "modified both" > ' > > >> > During the tests, this means that the following sequence occurs: >> > >> > 1) the shell opens "output" to redirect the difftool output >> > 2) difftool copies the empty "output" to the temporary directory >> > 3) difftool runs "ls" which writes to "output" >> > 4) difftool copies the empty "output" file back over the output of the >> > command >> > 5) the output files doesn't contain the expected output, causing the >> > test to fail >> > >> > Avoid this by writing the output into .git/ which will not be copied or >> > overwritten. >> >> It is a good idea to move these test output and expect test vectore >> files to a different place to make it easier to distinguish them >> from test input (e.g. "sub", "file", etc.) in general, but the >> description of the original problem sounds like it is just working >> around a bug to me. What am I missing? > > I think there is a bug, as described in the paragraph below, and this > test should be made independent of that. In light of the above I think > we can drop this patch and do this with that change instead. I, too, was scratching my head when the Windows issue was first reported. Thanks for clearing this up; fixing the blind "add ." certainly seems like the way to go. -- David -- 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