Christoph Bonitz 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 occurrences in this file
On Fri, Jul 25, 2014 at 12:05 AM, Junio C Hamano wrote:
> Johannes Sixt 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 that is certainly outside
On Thu, Jul 24, 2014 at 8:45 PM, Johannes Sixt 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 wron
Johannes Sixt 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
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 fil
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 revisi
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 test
On Mon, Jul 7, 2014 at 11:14 PM, Junio C Hamano 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 way?
I agree
Pete Wyckoff 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
> be in o
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 co
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
11 matches
Mail list logo
