]> git.ipfire.org Git - thirdparty/git.git/commit
t7800: don't rely on reuse_worktree_file()
authorJeff King <peff@peff.net>
Thu, 16 Jan 2020 18:19:40 +0000 (13:19 -0500)
committerJunio C Hamano <gitster@pobox.com>
Thu, 16 Jan 2020 22:48:26 +0000 (14:48 -0800)
commite4837b4406ae7a7192e22359dc94d69b8a8ef69d
tree919740ea7ba0c72d8b912cd12c7b495f28926a80
parentfbce03d3291e80b76a75d37a44ecf4ab238e6837
t7800: don't rely on reuse_worktree_file()

A test in t7800 tries to make sure that when git-difftool runs an
external tool that fails, it stops looking at files. Our fake failing
tool prints the file name it was asked to diff before exiting non-zero,
and then we confirm the output contains only that file.

However, this subtly relies on our internal reuse_worktree_file().
Because we're diffing between branches, the command run by difftool
might see:

  - the git-stored filename (e.g., "file"), if we decided that the
    working tree contents were up-to-date with the object in the index
    and HEAD, and we could reuse them

  - a temporary filename (e.g. "/tmp/abc123_file") if we had to dump the
    contents from the object database

If the latter case happens, then the test fails, because it's expecting
the string "file". I discovered this when debugging something unrelated
with reuse_worktree_file(). I _thought_ it should be able to be
triggered by a racy-git situation, but running:

  ./t7800-difftool.sh --stress --run=2,13

never seems to fail. However, by my reading of reuse_worktree_file(),
this would probably always fail under Cygwin, because it sets
NO_FAST_WORKING_DIRECTORY. At any rate, since reuse_worktree_file()
is meant to be an optimization that may or may not trigger, our test
should be robust either way.

Instead of checking the filename, let's just make sure we got a single
line of output (which would not be true if we continued after the first
failure).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t7800-difftool.sh