From: Pete Wyckoff <pw@padd.com>
To: Christoph Bonitz <ml.christophbonitz@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Test failure in t9814-git-p4-rename.sh - my environment or bad test?
Date: Sun, 6 Jul 2014 21:10:17 -0400 [thread overview]
Message-ID: <20140707011017.GA3802@padd.com> (raw)
In-Reply-To: <CABUJjW-iZU2Dp-yfuf302pNMuMj8NBXTvBW-0UHNxXdSWSk4Zw@mail.gmail.com>
ml.christophbonitz@gmail.com wrote on Sun, 06 Jul 2014 16:32 +0200:
> I'm trying to get the git p4 tests to pass on my machine (OS X
> Mavericks) from master before making some changes. I'm experiencing a
> test failure in "detect copies" of the rename test.
>
> The test creates file2 with some content, creates a few copies (each
> with a commit), then does the following (no git write operations
> omitted):
> echo "file2" >>file2 &&
> cp file2 file10 &&
> git add file2 file10 &&
> git commit -a -m "Modify and copy file2 to file10" &&
> ... (some non-write-operations) ...
> cp file2 file11 &&
> git add file11 &&
> git commit -a -m "Copy file2 to file11" &&
> git diff-tree -r -C --find-copies-harder HEAD &&
> src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2) &&
> test "$src" = file10 &&
>
> This is where it fails on my machine. The git diff-tree output is this
> :100644 100644 22a35c17c4c0779f75142036beef6ccd58525b9c
> 22a35c17c4c0779f75142036beef6ccd58525b9c C100 file2 file11
> so git diff-tree sees file2 as the copy source, not file10. In my
> opinion, the diff-tree result is legitimate (at that point, file2,
> file10 and file11 are identical). Later in the tests, after making
> more copies of file2, the conditions are more flexible, e.g.
> test "$src" = file10 || test "$src" = file11 || test "$src" = file12 &&
>
> IMO, the test discounts the legitimate possibility of diff-tree
> detecting file2 as source, making unnecessary assumptions about
> implementation details. Is this correct, or do I misunderstand the
> workings of diff-tree?
>
> I'd be grateful for advice, both on whether this is a bug, and if so,
> which branch to base a patch on.
I think your analysis is correct. And I agree that later tests
have noticed this ambiguity and added multiple comparisons like
you quote.
I'm not sure how to robustify this. At least doing the multiple
comparisons should make the tests work again. The goal of this
series of tests is to make sure that copy detection is working,
not to verify that the correct copy choice was made. That should
be in other (non-p4) tests.
Do send patches based on Junio's master. I can ack, and they'll
show up in a future git release.
Thanks!
-- Pete
next prev parent reply other threads:[~2014-07-07 1:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-06 14:32 Test failure in t9814-git-p4-rename.sh - my environment or bad test? Christoph Bonitz
2014-07-07 1:10 ` Pete Wyckoff [this message]
2014-07-07 21:14 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2014-07-23 21:26 Christoph Bonitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140707011017.GA3802@padd.com \
--to=pw@padd.com \
--cc=git@vger.kernel.org \
--cc=ml.christophbonitz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).