On Fri, Mar 22, 2013 at 4:05 PM, John Keeping <j...@keeping.me.uk> wrote:
> On Fri, Mar 22, 2013 at 03:53:38PM -0700, Junio C Hamano wrote:
>> John Keeping <j...@keeping.me.uk> 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
>> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html