On Thu, Jul 24, 2014 at 8:45 PM, Johannes Sixt j...@kdbg.org wrote:
Am 23.07.2014 23:28, schrieb Christoph Bonitz:
- test $src = file10 || test $src = file11
+ test $src = file2 || test $src = file10 || test $src = file11
You can't test for alternatives in this way. It's already wrong in
On Fri, Jul 25, 2014 at 12:05 AM, Junio C Hamano gits...@pobox.com wrote:
Johannes Sixt j...@kdbg.org writes:
I see a few other no-nos in the context of the changes, in particular,
pipelines where git is not the last command; these would not catch
failures in the git commands. But a fix for
Christoph Bonitz ml.christophbon...@gmail.com writes:
Apart from your change and the word wrap adjustments suggested by
Pete, would the following also make sense, to fix the other flaw
Johannes pointed out? With regards to failing, git diff-tree should be
idempotent. I think those are the two
Am 23.07.2014 23:28, schrieb Christoph Bonitz:
The scenario in the rename test makes unnecessary assumptions about
which file git file-tree will detect as a source for a copy-operations.
Furthermore, copy detection is not tested by checking the resulting
perforce revision history via p4
Johannes Sixt j...@kdbg.org writes:
@@ -177,7 +175,7 @@ test_expect_success 'detect copies' '
level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 |
cut -d -f5 | sed s/C0*//)
test -n $level test $level -gt 0 test $level -lt 98
src=$(git diff-tree -r -C
On Mon, Jul 7, 2014 at 11:14 PM, Junio C Hamano gits...@pobox.com wrote:
Choosing any of these as the copy source is fine is a sensible way
to fix the problem with this test. Would it be a better solution to
avoid having multiple/ambiguous copy source candidates in the first
place, by the
The scenario in the rename test makes unnecessary assumptions about
which file git file-tree will detect as a source for a copy-operations.
Furthermore, copy detection is not tested by checking the resulting
perforce revision history via p4 filelog, but via git diff-tree.
This patch makes the
ml.christophbon...@gmail.com wrote on Wed, 23 Jul 2014 23:28 +0200:
The scenario in the rename test makes unnecessary assumptions about
which file git file-tree will detect as a source for a copy-operations.
Furthermore, copy detection is not tested by checking the resulting
perforce revision
Pete Wyckoff p...@padd.com writes:
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
Hi,
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
ml.christophbon...@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,
11 matches
Mail list logo
