Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Sun, Sep 8, 2013 at 6:45 PM, Jeff King wrote: > On Sun, Sep 08, 2013 at 06:25:45PM -0500, Felipe Contreras wrote: > >> > And I do not think it is a problem. The point of the function is not to >> > abstract away the idea of comparison. The point is to give a hook for >> > people on systems without "diff -u" to run the test suite. >> >> The point according to whom? I say it's the other way around. > > The point according to 82ebb0b (add test_cmp function for test scripts, > 2008-03-12). I wish I had simply called it test_diff back then, and then > this conversation could have never occurred. So? That's the original intention from the author, it's not the point of the function from the project's point of view, or what the point _should_ be. >> Either way the fact that others are doing it differently doesn't mean >> that's the best way, that would be argumentum ad populum, and mothers >> are keen to remind us that if other kids are jumping the bridge, that >> doesn't mean we should too. > > Did I once say "my way of thinking about it is the best way"? No. I said > "I think it is a matter of preference". I mentioned other systems using > a particular ordering to show that the set of people who prefer it the > other way is non-zero. That doesn't show it they prefer it that way. They could be in the same situation than us, they might prefer it a different way, but they are stuck with what they chose long time ago. > Feel free to respond, but I have no interest in discussing this any > further with you. This thread has become a giant time sink, and I have > nothing else to say on the matter that I have not already said. It's all right, I don't think you were contributing much more than; diff -u does $expect $actual. In case the above gets misconstrued as an insult, it's not meant that way, Jeff said it himself; he cannot depart his view away from the diff -u implementation. -- Felipe Contreras -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Sun, Sep 08, 2013 at 06:25:45PM -0500, Felipe Contreras wrote: > > And I do not think it is a problem. The point of the function is not to > > abstract away the idea of comparison. The point is to give a hook for > > people on systems without "diff -u" to run the test suite. > > The point according to whom? I say it's the other way around. The point according to 82ebb0b (add test_cmp function for test scripts, 2008-03-12). I wish I had simply called it test_diff back then, and then this conversation could have never occurred. > Either way the fact that others are doing it differently doesn't mean > that's the best way, that would be argumentum ad populum, and mothers > are keen to remind us that if other kids are jumping the bridge, that > doesn't mean we should too. Did I once say "my way of thinking about it is the best way"? No. I said "I think it is a matter of preference". I mentioned other systems using a particular ordering to show that the set of people who prefer it the other way is non-zero. Feel free to respond, but I have no interest in discussing this any further with you. This thread has become a giant time sink, and I have nothing else to say on the matter that I have not already said. -Peff -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Sun, Sep 8, 2013 at 12:02 AM, Jeff King wrote: > On Sat, Sep 07, 2013 at 11:52:10PM -0500, Felipe Contreras wrote: > >> > Ah, you mean "if you think that the compare function should behave like >> > C *_cmp functions, it should be A-B". Perhaps it is simply that I do not >> > think of the function in those terms, but more like "show me the >> > differences from B to A". >> >> But that is the problem, you are unable to ignore the implementation. >> You don't see test_cmp(), you see 'diff -u'. > > Yes, I already said earlier in the thread: > > I certainly think of "test_cmp A B" as "differences from A to B", and > the order makes sense. IOW, the "test_cmp is diff" abstraction is > leaky, and that is fine (if it were not leaky, then order would not > matter at all, but it clearly does). Then I don't think you can give a fair and objective opinion about what should be the ideal ordering of the arguments. You would be forever biased to whatever is the order of 'diff -u'. > And I do not think it is a problem. The point of the function is not to > abstract away the idea of comparison. The point is to give a hook for > people on systems without "diff -u" to run the test suite. The point according to whom? I say it's the other way around. >> > John mentioned JUnit, NUnit, and PHPUnit earlier in the thread. I >> > believe that Ruby's Test::Unit::Assertions also has >> > assert_equal(expected, actual). >> >> That's because they all do first expect, then actual. >> >> assert_equal( expected, actual, failure_message = nil ) >> assert_not_equal( expected, actual, failure_message = nil ) >> >> That's why. > > I do not see any reason why "not_equal" would not also work as > "assert_not_equal(actual, expected)". Maybe I am missing your point. All right, maybe it's because Ruby started in Japan, and their sentences have very different orderings, maybe it's legacy from another test framework, maybe there's no reason at all and somebody just randomly picked them. Either way the fact that others are doing it differently doesn't mean that's the best way, that would be argumentum ad populum, and mothers are keen to remind us that if other kids are jumping the bridge, that doesn't mean we should too. -- Felipe Contreras -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Sun, Sep 8, 2013 at 1:33 PM, Junio C Hamano wrote: > Jeff King writes: > Calling the abstraction "test_diff" might have avoided the wasted > brain bandwidth in this thread, but I do not think renaming it in > test-lib-functions.sh is worth the trouble, either ;-) Yes, but then it wouldn't be clear what's the main purpose of test_diff(). Primarily what we want is to check that they are the same. The diff is secondary, and it's not actually *needed*. -- Felipe Contreras -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
Jeff King writes:
>> A(ny) sanely defined "compare A with B" function should yield the
>> result of subtracting B from A, i.e. cmp(A,B) should be like (A-B).
>> That is what you feed qsort() and bsearch() (it is not limited to C;
>> you see the same in "sort { $a <=> $b }"). The definition naturally
>> makes "cmp(A,B) < 0" like "A < B" and "cmp(A,B) > 0" like "A > B".
>> ---
>
> Ah, you mean "if you think that the compare function should behave like
> C *_cmp functions, it should be A-B". Perhaps it is simply that I do not
> think of the function in those terms, but more like "show me the
> differences from B to A".
>
>> > Otherwise why would so many
>> > existing test frameworks do it the other way?
>>
>> Which many existing frameworks do it the other way?
>
> John mentioned JUnit, NUnit, and PHPUnit earlier in the thread. I
> believe that Ruby's Test::Unit::Assertions also has
> assert_equal(expected, actual).
Especially the last one can be excused. "is A and B equal" is a
binary between "yes" and "no". If A and B are equal, B and A are
equal, and it becomes more like "which endianness is correct?" as
you mentioned earlier.
I think the real cause of confusion is that "cmp(1)" is not a
comparison in that sense but is an equality check; "test_cmp" has a
dual purpose in that its primary use as "did the previous step
produce correct result?" is an equality check and the order does not
really matter, but its secondary purpose, to show how the actual
output deviated from the norm, has to be done by subtracting the
expected result from the actual result.
As I said, I am somewhat sympathetic to those who want to see such
subtraction spelled as cmp(Actual,Expect), but we are so used to the
order "diff(1)" takes expect and actual to do that subtraction in
that order, so using diff(Expect,Actual) order is not that wrong.
Calling the abstraction "test_diff" might have avoided the wasted
brain bandwidth in this thread, but I do not think renaming it in
test-lib-functions.sh is worth the trouble, either ;-)
--
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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
From: "Jeff King" Sent: Sunday, September 08, 2013 5:06 AM Was there some objective argument made that I missed? Here's more; human semantics: Isn't this one of those "pick any two from three" tasks: 'human', 'objective', 'argument'. Only 1/6 of the time is an 'objective' answer the result. Philip "Between thee and me there's nowt so queer as fowk, and I ain't so sure about thee." old Yorkshire saying. -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Sat, Sep 07, 2013 at 11:52:10PM -0500, Felipe Contreras wrote: > > Ah, you mean "if you think that the compare function should behave like > > C *_cmp functions, it should be A-B". Perhaps it is simply that I do not > > think of the function in those terms, but more like "show me the > > differences from B to A". > > But that is the problem, you are unable to ignore the implementation. > You don't see test_cmp(), you see 'diff -u'. Yes, I already said earlier in the thread: I certainly think of "test_cmp A B" as "differences from A to B", and the order makes sense. IOW, the "test_cmp is diff" abstraction is leaky, and that is fine (if it were not leaky, then order would not matter at all, but it clearly does). And I do not think it is a problem. The point of the function is not to abstract away the idea of comparison. The point is to give a hook for people on systems without "diff -u" to run the test suite. > > John mentioned JUnit, NUnit, and PHPUnit earlier in the thread. I > > believe that Ruby's Test::Unit::Assertions also has > > assert_equal(expected, actual). > > That's because they all do first expect, then actual. > > assert_equal( expected, actual, failure_message = nil ) > assert_not_equal( expected, actual, failure_message = nil ) > > That's why. I do not see any reason why "not_equal" would not also work as "assert_not_equal(actual, expected)". Maybe I am missing your point. -Peff -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Sat, Sep 7, 2013 at 11:26 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 11:13:10PM -0500, Felipe Contreras wrote:
>
>> > If the reasoning is "cmp(actual, expect) makes more sense to humans"
>> > then I do not think it is universal.
>>
>> No.
>>
>> ---
>> A(ny) sanely defined "compare A with B" function should yield the
>> result of subtracting B from A, i.e. cmp(A,B) should be like (A-B).
>> That is what you feed qsort() and bsearch() (it is not limited to C;
>> you see the same in "sort { $a <=> $b }"). The definition naturally
>> makes "cmp(A,B) < 0" like "A < B" and "cmp(A,B) > 0" like "A > B".
>> ---
>
> Ah, you mean "if you think that the compare function should behave like
> C *_cmp functions, it should be A-B". Perhaps it is simply that I do not
> think of the function in those terms, but more like "show me the
> differences from B to A".
But that is the problem, you are unable to ignore the implementation.
You don't see test_cmp(), you see 'diff -u'.
>> > Otherwise why would so many
>> > existing test frameworks do it the other way?
>>
>> Which many existing frameworks do it the other way?
>
> John mentioned JUnit, NUnit, and PHPUnit earlier in the thread. I
> believe that Ruby's Test::Unit::Assertions also has
> assert_equal(expected, actual).
That's because they all do first expect, then actual.
assert_equal( expected, actual, failure_message = nil )
assert_not_equal( expected, actual, failure_message = nil )
That's why.
>> > Or any number of variations. I'm sure you will say "but those seem
>> > awkward and unlike how I think about it". But that was my point; it
>> > seems to be a matter of preference.
>>
>> Really? You think any sane human being would prefer:
>>
>> Computer, given that we expect B, how does A differ?
>>
>> To:
>>
>> Computer, compare A with B
>
> I already said that is how I think about it. If you want to call me notn
> sane, feel free. But I do not see that this line of discussion is going
> anywhere productive.
Again, that's because you are already thinking on the resulting diff,
based on the 'diff -u' command, but that's not in question here. Even
if test_cmp() didn't return an diff (it just ran cmp), it would be
useful, as ultimately we want to test for failures. Ultimately what we
want is to check that A is equal to B, so it's natural to tell the
computer "compare A with B", and if you don't think so, then yeah, I
think you are insane.
--
Felipe Contreras
--
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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Sat, Sep 07, 2013 at 11:13:10PM -0500, Felipe Contreras wrote:
> > If the reasoning is "cmp(actual, expect) makes more sense to humans"
> > then I do not think it is universal.
>
> No.
>
> ---
> A(ny) sanely defined "compare A with B" function should yield the
> result of subtracting B from A, i.e. cmp(A,B) should be like (A-B).
> That is what you feed qsort() and bsearch() (it is not limited to C;
> you see the same in "sort { $a <=> $b }"). The definition naturally
> makes "cmp(A,B) < 0" like "A < B" and "cmp(A,B) > 0" like "A > B".
> ---
Ah, you mean "if you think that the compare function should behave like
C *_cmp functions, it should be A-B". Perhaps it is simply that I do not
think of the function in those terms, but more like "show me the
differences from B to A".
> > Otherwise why would so many
> > existing test frameworks do it the other way?
>
> Which many existing frameworks do it the other way?
John mentioned JUnit, NUnit, and PHPUnit earlier in the thread. I
believe that Ruby's Test::Unit::Assertions also has
assert_equal(expected, actual).
> > Or any number of variations. I'm sure you will say "but those seem
> > awkward and unlike how I think about it". But that was my point; it
> > seems to be a matter of preference.
>
> Really? You think any sane human being would prefer:
>
> Computer, given that we expect B, how does A differ?
>
> To:
>
> Computer, compare A with B
I already said that is how I think about it. If you want to call me not
sane, feel free. But I do not see that this line of discussion is going
anywhere productive.
-Peff
--
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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Sat, Sep 7, 2013 at 11:13 PM, Felipe Contreras
wrote:
> On Sat, Sep 7, 2013 at 11:06 PM, Jeff King wrote:
>> On Sat, Sep 07, 2013 at 10:11:49PM -0500, Felipe Contreras wrote:
>>
>>> > Though I prefer the current, I can certainly live and adapt to a changed
>>> > standard, and I do not mind doing so if there is a good reason. But I've
>>> > yet to see any argument beyond "it is not what I like". Which to me
>>> > argues for the status quo as the path of least resistance.
>>>
>>> Didn't Junio already provided reasoning?
>>
>> If the reasoning is "cmp(actual, expect) makes more sense to humans"
>> then I do not think it is universal.
>
> No.
>
> ---
> A(ny) sanely defined "compare A with B" function should yield the
> result of subtracting B from A, i.e. cmp(A,B) should be like (A-B).
> That is what you feed qsort() and bsearch() (it is not limited to C;
> you see the same in "sort { $a <=> $b }"). The definition naturally
> makes "cmp(A,B) < 0" like "A < B" and "cmp(A,B) > 0" like "A > B".
> ---
>
>> Otherwise why would so many
>> existing test frameworks do it the other way?
>
> Which many existing frameworks do it the other way?
>
>>> Here's more; human semantics:
>>>
>>> Computer, compare A with B
>>> cmp(A, B)
>>>
>>> Why would I write?
>>>
>>> cmp(B, A)
>>>
>>> Could you even construct an English sentence that starts with B, and then A?
>>
>> "Computer, given that we expect B, how does A differ?". Or "Computer, we
>> expect B; does A match it?"
>>
>> Or any number of variations. I'm sure you will say "but those seem
>> awkward and unlike how I think about it". But that was my point; it
>> seems to be a matter of preference.
>
> Really? You think any sane human being would prefer:
>
> Computer, given that we expect B, how does A differ?
And btw, that could barely be translated to cmp(B, A), probably cmp_given(B, A).
--
Felipe Contreras
--
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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Sat, Sep 7, 2013 at 11:06 PM, Jeff King wrote:
> On Sat, Sep 07, 2013 at 10:11:49PM -0500, Felipe Contreras wrote:
>
>> > Though I prefer the current, I can certainly live and adapt to a changed
>> > standard, and I do not mind doing so if there is a good reason. But I've
>> > yet to see any argument beyond "it is not what I like". Which to me
>> > argues for the status quo as the path of least resistance.
>>
>> Didn't Junio already provided reasoning?
>
> If the reasoning is "cmp(actual, expect) makes more sense to humans"
> then I do not think it is universal.
No.
---
A(ny) sanely defined "compare A with B" function should yield the
result of subtracting B from A, i.e. cmp(A,B) should be like (A-B).
That is what you feed qsort() and bsearch() (it is not limited to C;
you see the same in "sort { $a <=> $b }"). The definition naturally
makes "cmp(A,B) < 0" like "A < B" and "cmp(A,B) > 0" like "A > B".
---
> Otherwise why would so many
> existing test frameworks do it the other way?
Which many existing frameworks do it the other way?
>> Here's more; human semantics:
>>
>> Computer, compare A with B
>> cmp(A, B)
>>
>> Why would I write?
>>
>> cmp(B, A)
>>
>> Could you even construct an English sentence that starts with B, and then A?
>
> "Computer, given that we expect B, how does A differ?". Or "Computer, we
> expect B; does A match it?"
>
> Or any number of variations. I'm sure you will say "but those seem
> awkward and unlike how I think about it". But that was my point; it
> seems to be a matter of preference.
Really? You think any sane human being would prefer:
Computer, given that we expect B, how does A differ?
To:
Computer, compare A with B
--
Felipe Contreras
--
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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Sat, Sep 07, 2013 at 10:11:49PM -0500, Felipe Contreras wrote: > > Though I prefer the current, I can certainly live and adapt to a changed > > standard, and I do not mind doing so if there is a good reason. But I've > > yet to see any argument beyond "it is not what I like". Which to me > > argues for the status quo as the path of least resistance. > > Didn't Junio already provided reasoning? If the reasoning is "cmp(actual, expect) makes more sense to humans" then I do not think it is universal. Otherwise why would so many existing test frameworks do it the other way? And that is why I said it seems more like an issue of personal preference than a universal truth. Was there some objective argument made that I missed? > Here's more; human semantics: > > Computer, compare A with B > cmp(A, B) > > Why would I write? > > cmp(B, A) > > Could you even construct an English sentence that starts with B, and then A? "Computer, given that we expect B, how does A differ?". Or "Computer, we expect B; does A match it?" Or any number of variations. I'm sure you will say "but those seem awkward and unlike how I think about it". But that was my point; it seems to be a matter of preference. -Peff -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Wed, Sep 4, 2013 at 1:36 PM, Jeff King wrote: > On Wed, Sep 04, 2013 at 10:38:03AM -0700, Junio C Hamano wrote: > >> >> This is way off tangent, but I am somewhat sympathetic to Felipe's >> >> "compare actual with expect", with reservations. >> > >> > This isn't an argument either way, but note that JUnit (and NUnit and >> > PHPUnit) all have assertEquals methods that take the arguments in the >> > order "expect, actual". I've always assumed that Git's test framework >> > was imitating that,... >> >> No. See 82ebb0b6 (add test_cmp function for test scripts, >> 2008-03-12). The "test_cmp" was a replacement for "diff -u", and >> the same order we fed "diff -u", i.e. expect then actual, was >> carried over. > > I don't think it was intentional at the time. But over the intervening 5 > years, I have noticed that I certainly think of "test_cmp A B" as > "differences from A to B", and the order makes sense. IOW, the "test_cmp > is diff" abstraction is leaky, and that is fine (if it were not leaky, > then order would not matter at all, but it clearly does). > > But let's take a step back. This seems like an endian-ness issue to me. > I.e., some people prefer one order for test assertions, and other people > prefer the other. Is anyone actually right, or is this simply a matter > of preference? And if it is simply a matter of preference, then why > bother going through the pain of changing the current project standard? > > Though I prefer the current, I can certainly live and adapt to a changed > standard, and I do not mind doing so if there is a good reason. But I've > yet to see any argument beyond "it is not what I like". Which to me > argues for the status quo as the path of least resistance. Didn't Junio already provided reasoning? Here's more; human semantics: Computer, compare A with B cmp(A, B) Why would I write? cmp(B, A) Could you even construct an English sentence that starts with B, and then A? -- Felipe Contreras -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
Jeff King writes: > On Wed, Sep 04, 2013 at 10:38:03AM -0700, Junio C Hamano wrote: > >> >> This is way off tangent, but I am somewhat sympathetic to Felipe's >> >> "compare actual with expect", with reservations. >> > >> > This isn't an argument either way, but note that JUnit (and NUnit and >> > PHPUnit) all have assertEquals methods that take the arguments in the >> > order "expect, actual". I've always assumed that Git's test framework >> > was imitating that,... >> >> No. See 82ebb0b6 (add test_cmp function for test scripts, >> 2008-03-12). The "test_cmp" was a replacement for "diff -u", and >> the same order we fed "diff -u", i.e. expect then actual, was >> carried over. > > I don't think it was intentional at the time. I do not think so, either. The only thing we cared about was "are they equal". And from the point of view of test_cmp exit status, that still the only thing we care about. Comparison to see which is greater is a superset of equality check we needed, and in that context, the order did not and does not matter. One only starts to notice the order of comparison when one starts thinking about the comparison in terms of "what is subtracted from what", and at that point, one realizes that "diff A B" that gives us what was lost from A to B as "-" and what was gained in B relative to A as "+" is showing the result of subtracting A from B. And that subtraction is backwards from the cmp(A,B) that subtracts B from A, which is the usual convention. > Though I prefer the current, I can certainly live and adapt to a changed > standard, and I do not mind doing so if there is a good reason. But I've > yet to see any argument beyond "it is not what I like". Which to me > argues for the status quo as the path of least resistance. As I think test_cmp is primarily about equality comparison, I do not think it is worth switching and adapting. Switching makes sense only in my dreams where we did not have to worry about in-flight topics and people's brains that are used to the current order. That is exactly where my "with reservations" came from. -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Wed, Sep 04, 2013 at 10:38:03AM -0700, Junio C Hamano wrote: > >> This is way off tangent, but I am somewhat sympathetic to Felipe's > >> "compare actual with expect", with reservations. > > > > This isn't an argument either way, but note that JUnit (and NUnit and > > PHPUnit) all have assertEquals methods that take the arguments in the > > order "expect, actual". I've always assumed that Git's test framework > > was imitating that,... > > No. See 82ebb0b6 (add test_cmp function for test scripts, > 2008-03-12). The "test_cmp" was a replacement for "diff -u", and > the same order we fed "diff -u", i.e. expect then actual, was > carried over. I don't think it was intentional at the time. But over the intervening 5 years, I have noticed that I certainly think of "test_cmp A B" as "differences from A to B", and the order makes sense. IOW, the "test_cmp is diff" abstraction is leaky, and that is fine (if it were not leaky, then order would not matter at all, but it clearly does). But let's take a step back. This seems like an endian-ness issue to me. I.e., some people prefer one order for test assertions, and other people prefer the other. Is anyone actually right, or is this simply a matter of preference? And if it is simply a matter of preference, then why bother going through the pain of changing the current project standard? Though I prefer the current, I can certainly live and adapt to a changed standard, and I do not mind doing so if there is a good reason. But I've yet to see any argument beyond "it is not what I like". Which to me argues for the status quo as the path of least resistance. -Peff -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
John Keeping writes: > On Wed, Sep 04, 2013 at 09:47:12AM -0700, Junio C Hamano wrote: >> Jonathan Nieder writes: >> >> > test_cmp_rev follows the same order of arguments a "diff -u" and >> > produces the same output as plain "git diff". It's perfectly readable >> > and normal. >> >> This is way off tangent, but I am somewhat sympathetic to Felipe's >> "compare actual with expect", with reservations. > > This isn't an argument either way, but note that JUnit (and NUnit and > PHPUnit) all have assertEquals methods that take the arguments in the > order "expect, actual". I've always assumed that Git's test framework > was imitating that,... No. See 82ebb0b6 (add test_cmp function for test scripts, 2008-03-12). The "test_cmp" was a replacement for "diff -u", and the same order we fed "diff -u", i.e. expect then actual, was carried over. -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Wed, Sep 04, 2013 at 09:47:12AM -0700, Junio C Hamano wrote: > Jonathan Nieder writes: > > > test_cmp_rev follows the same order of arguments a "diff -u" and > > produces the same output as plain "git diff". It's perfectly readable > > and normal. > > This is way off tangent, but I am somewhat sympathetic to Felipe's > "compare actual with expect", with reservations. This isn't an argument either way, but note that JUnit (and NUnit and PHPUnit) all have assertEquals methods that take the arguments in the order "expect, actual". I've always assumed that Git's test framework was imitating that, although I have no idea why that particular order is chosen and is so common. -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
Jonathan Nieder writes:
> test_cmp_rev follows the same order of arguments a "diff -u" and
> produces the same output as plain "git diff". It's perfectly readable
> and normal.
This is way off tangent, but I am somewhat sympathetic to Felipe's
"compare actual with expect", with reservations.
If one ignores all other constraints and focuses solely on the order
of argument test_cmp takes, one would realize that it is backwards.
A(ny) sanely defined "compare A with B" function should yield the
result of subtracting B from A, i.e. cmp(A,B) should be like (A-B).
That is what you feed qsort() and bsearch() (it is not limited to C;
you see the same in "sort { $a <=> $b }"). The definition naturally
makes "cmp(A,B) < 0" like "A < B" and "cmp(A,B) > 0" like "A > B".
But unfortunately, test_cmp is defined in terms of "diff -u" by
feeding its parameters in the same order as given. "test_cmp A B"
just turns into "diff -u A B".
Now, we _do_ want to see "diff -u expect actual", so that in the
output, what is _missing_ in the actual output compared to the
expected output is marked with "-", and what is _excess_ is marked
with "+". If you think about it, this output from "diff -u expect
actual" is giving us the result of subtracting expect from actual.
If we want to express it in terms of "cmp", we should be writing
"cmp(actual,expect)", not "cmp(expect,actual)". The latter is to
subtract actual from expect, which is backwards.
It would have been better if a wrapper around "diff" to give us a
higher level "comparison" semantics, test_cmp, had been written in
such a way that hid this backward behaviour of "diff", when it was
introduced to replace hardcoded "diff -u".
I'd actually be ecstatic if one morning when I get up, I find that
test_cmp implementation were replaced with (the moral equivalent of)
test_cmp () {
diff -u "$2" "$1"
}
and all the callsites of test_cmp in the test scripts in all the
topic branches in flight were also swapped to "test_cmp actual
expect" without anybody having to worry about mismerges, merge
conflicts and confusing people who are used to the current order for
the past 5 years.
But I do not think that is going to happen without a careful
planning. We may be able to manage the code somehow (we can drop
all the topics in flight immediately after a release, apply the
"swap the order" big patch, and rebase all the topics on top), but
retraining people would not be instantaneous "flag day" event, and
we will see mistakes for a few months after doing so.
Oh, well.
--
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
Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Tue, Sep 3, 2013 at 12:31 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> There are two ways to fix an inconsistency, the other way is to fix >> test_cmp. But that would be a change, and change is not welcome in >> Git. > > If you want to do "test_cmp $actual $expect", you would have to > first "fix" people's expectation that "diff A B" produces a change > necessary to bring A to B, which would not likely to happen. We do > the 'test_cmp expect actual' for a reason. No, you just do "diff B A". -- Felipe Contreras -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Tue, Sep 3, 2013 at 12:04 PM, Jonathan Nieder wrote: > SZEDER Gábor wrote: >> On Tue, Sep 03, 2013 at 08:39:54AM -0500, Felipe Contreras wrote: > >>> There are two ways to fix an inconsistency, the other way is to fix >>> test_cmp. But that would be a change, and change is not welcome in >>> Git. >> >> It depends on the change, I suppose. I agree, changing 3k+ lines just >> to avoid yoda conditions... I doubt the gain worth the code churn. > > Especially when the idiom being changed is not even being made better. > ;-) But it is better. > test_cmp_rev follows the same order of arguments a "diff -u" and > produces the same output as plain "git diff". It's perfectly readable > and normal. I think Felipe is pushing buttons and testing boundaries. Those are irrelevant implementation details. -- Felipe Contreras -- 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
Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
Junio C Hamano writes: > Felipe Contreras writes: > >> There are two ways to fix an inconsistency, the other way is to fix >> test_cmp. But that would be a change, and change is not welcome in >> Git. > > If you want to do "test_cmp $actual $expect", you would have to > first "fix" people's expectation that "diff A B" produces a change > necessary to bring A to B, which would not likely to happen. We do > the 'test_cmp expect actual' for a reason. By the way, I found the other changes (especially the last one) very sensible. -- 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
Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
Felipe Contreras writes: > There are two ways to fix an inconsistency, the other way is to fix > test_cmp. But that would be a change, and change is not welcome in > Git. If you want to do "test_cmp $actual $expect", you would have to first "fix" people's expectation that "diff A B" produces a change necessary to bring A to B, which would not likely to happen. We do the 'test_cmp expect actual' for a reason. -- 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
Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Tue, Sep 03, 2013 at 10:04:19AM -0700, Jonathan Nieder wrote: > > It depends on the change, I suppose. I agree, changing 3k+ lines just > > to avoid yoda conditions... I doubt the gain worth the code churn. > > Especially when the idiom being changed is not even being made better. > ;-) Yes. IMHO it is not just "not worth the churn" but actively making the code less readable. > While at it, I rerolled the other patches from the series to clarify > their commit messages (replacing "fix " with a fuller > description). The series looks fine to me, modulo the fix up in v2 of 4/4. -Peff -- 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
[PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
SZEDER Gábor wrote: > On Tue, Sep 03, 2013 at 08:39:54AM -0500, Felipe Contreras wrote: >> There are two ways to fix an inconsistency, the other way is to fix >> test_cmp. But that would be a change, and change is not welcome in >> Git. > > It depends on the change, I suppose. I agree, changing 3k+ lines just > to avoid yoda conditions... I doubt the gain worth the code churn. Especially when the idiom being changed is not even being made better. ;-) test_cmp_rev follows the same order of arguments a "diff -u" and produces the same output as plain "git diff". It's perfectly readable and normal. I think Felipe is pushing buttons and testing boundaries. But in the process came a report of a missing test_cmp_rev use, which is useful. Patch follows. While at it, I rerolled the other patches from the series to clarify their commit messages (replacing "fix " with a fuller description). Improvements welcome, as always. Thanks. Felipe Contreras (3): rev-parse test: modernize quoting and whitespace rev-parse test: use test_must_fail, not "if ; then false; fi" rev-parse test: use standard test functions for setup Jonathan Nieder (1): rev-parse test: use test_cmp instead of "test" builtin t/t6101-rev-parse-parents.sh | 110 +++ 1 file changed, 79 insertions(+), 31 deletions(-) -- 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
Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Tue, Sep 03, 2013 at 08:39:54AM -0500, Felipe Contreras wrote:
> On Tue, Sep 3, 2013 at 6:10 AM, SZEDER Gábor wrote:
> > On Tue, Sep 03, 2013 at 05:45:06AM -0500, Felipe Contreras wrote:
> >> On Tue, Sep 3, 2013 at 3:03 AM, Jeff King wrote:
> >> > On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZEDER Gábor wrote:
> >> >
> >> >> > I wonder if we should have a:
> >> >> >
> >> >> > test_cmp_args () {
> >> >> > echo "$1" >expect &&
> >> >> > echo "$1" >actual &&
> >> >> > test_cmp expect actual
> >> >> > }
> >> >> >
> >> >> > to let these remain one-liners like:
> >> >> >
> >> >> > test_cmp_args "$(git rev-parse start)" "$(git rev-parse
> >> >> > final^1^1^1)"
BTW, why not just use the already existing
test_cmp_rev start final^1^1^1
helper function to get usable output on error and still keep these as
one-liners?
> >> >> This idea come up before, but there is one flaw which makes this
> >> >> function less useful: a non-zero exit code of the commands in the
> >> >> command substitutions would be lost.
> >> >
> >> > Good point. You'd probably have to do something gross with eval, like:
> >> >
> >> > test_cmp_args () {
> >> > eval "$1" >expect &&
> >> > eval "$2" >actual &&
> >>
> >> I don't see any reason to perpetuate these yoda comparisons.
> >>
> >> eval "$2" >expect &&
> >> eval "$1" >actual &&
> >
> > I do. Your proposal requires the arguments in the reverse order
> > compared to test_cmp. That inconsistency would be far worse than
> > test_cmp_args "$expect" "$actual".
>
> There are two ways to fix an inconsistency, the other way is to fix
> test_cmp. But that would be a change, and change is not welcome in
> Git.
It depends on the change, I suppose. I agree, changing 3k+ lines just
to avoid yoda conditions... I doubt the gain worth the code churn.
Best,
Gábor
--
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
Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Tue, Sep 3, 2013 at 6:10 AM, SZEDER Gábor wrote:
> On Tue, Sep 03, 2013 at 05:45:06AM -0500, Felipe Contreras wrote:
>> On Tue, Sep 3, 2013 at 3:03 AM, Jeff King wrote:
>> > On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZEDER Gábor wrote:
>> >
>> >> > I wonder if we should have a:
>> >> >
>> >> > test_cmp_args () {
>> >> > echo "$1" >expect &&
>> >> > echo "$1" >actual &&
>> >> > test_cmp expect actual
>> >> > }
>> >> >
>> >> > to let these remain one-liners like:
>> >> >
>> >> > test_cmp_args "$(git rev-parse start)" "$(git rev-parse final^1^1^1)"
>> >>
>> >> This idea come up before, but there is one flaw which makes this
>> >> function less useful: a non-zero exit code of the commands in the
>> >> command substitutions would be lost.
>> >
>> > Good point. You'd probably have to do something gross with eval, like:
>> >
>> > test_cmp_args () {
>> > eval "$1" >expect &&
>> > eval "$2" >actual &&
>>
>> I don't see any reason to perpetuate these yoda comparisons.
>>
>> eval "$2" >expect &&
>> eval "$1" >actual &&
>
> I do. Your proposal requires the arguments in the reverse order
> compared to test_cmp. That inconsistency would be far worse than
> test_cmp_args "$expect" "$actual".
There are two ways to fix an inconsistency, the other way is to fix
test_cmp. But that would be a change, and change is not welcome in
Git.
For this reason alone I would prefer 'test "$actual" = expected', than
the yodaish 'test_cmp_args "expected" "$actual"'.
--
Felipe Contreras
--
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
Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Tue, Sep 03, 2013 at 05:45:06AM -0500, Felipe Contreras wrote:
> On Tue, Sep 3, 2013 at 3:03 AM, Jeff King wrote:
> > On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZEDER Gábor wrote:
> >
> >> > I wonder if we should have a:
> >> >
> >> > test_cmp_args () {
> >> > echo "$1" >expect &&
> >> > echo "$1" >actual &&
> >> > test_cmp expect actual
> >> > }
> >> >
> >> > to let these remain one-liners like:
> >> >
> >> > test_cmp_args "$(git rev-parse start)" "$(git rev-parse final^1^1^1)"
> >>
> >> This idea come up before, but there is one flaw which makes this
> >> function less useful: a non-zero exit code of the commands in the
> >> command substitutions would be lost.
> >
> > Good point. You'd probably have to do something gross with eval, like:
> >
> > test_cmp_args () {
> > eval "$1" >expect &&
> > eval "$2" >actual &&
>
> I don't see any reason to perpetuate these yoda comparisons.
>
> eval "$2" >expect &&
> eval "$1" >actual &&
I do. Your proposal requires the arguments in the reverse order
compared to test_cmp. That inconsistency would be far worse than
test_cmp_args "$expect" "$actual".
> > test_cmp expect actual
> > }
Best,
Gábor
--
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
Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Tue, Sep 3, 2013 at 3:03 AM, Jeff King wrote:
> On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZEDER Gábor wrote:
>
>> > I wonder if we should have a:
>> >
>> > test_cmp_args () {
>> > echo "$1" >expect &&
>> > echo "$1" >actual &&
>> > test_cmp expect actual
>> > }
>> >
>> > to let these remain one-liners like:
>> >
>> > test_cmp_args "$(git rev-parse start)" "$(git rev-parse final^1^1^1)"
>>
>> This idea come up before, but there is one flaw which makes this
>> function less useful: a non-zero exit code of the commands in the
>> command substitutions would be lost.
>
> Good point. You'd probably have to do something gross with eval, like:
>
> test_cmp_args () {
> eval "$1" >expect &&
> eval "$2" >actual &&
I don't see any reason to perpetuate these yoda comparisons.
eval "$2" >expect &&
eval "$1" >actual &&
> test_cmp expect actual
> }
--
Felipe Contreras
--
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
Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZEDER Gábor wrote:
> > I wonder if we should have a:
> >
> > test_cmp_args () {
> > echo "$1" >expect &&
> > echo "$1" >actual &&
> > test_cmp expect actual
> > }
> >
> > to let these remain one-liners like:
> >
> > test_cmp_args "$(git rev-parse start)" "$(git rev-parse final^1^1^1)"
>
> This idea come up before, but there is one flaw which makes this
> function less useful: a non-zero exit code of the commands in the
> command substitutions would be lost.
Good point. You'd probably have to do something gross with eval, like:
test_cmp_args () {
eval "$1" >expect &&
eval "$2" >actual &&
test_cmp expect actual
}
but then the callers have to deal with an extra layer of quoting. Not
worth it to save a few lines.
Thanks for a sanity check.
-Peff
--
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
Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
Hi,
On Tue, Sep 03, 2013 at 03:12:56AM -0400, Jeff King wrote:
> On Mon, Sep 02, 2013 at 01:30:38AM -0500, Felipe Contreras wrote:
>
> > Just as 5 == X is weird, so is comparing first the expected value, and
> > then the value we are testing. So switch them around.
>
> Actually, our normal comparison order for test output is "test_cmp
> expect actual", as it shows a test failure as a diff with the expected
> output as the base (i.e., the diff shows what went wrong).
>
> That reasoning does not apply to "test a = b", which shows no output at
> all. However, if you want to clean up and modernize these tests, it
> would probably be better to simply convert them to use test_cmp.
>
> I wonder if we should have a:
>
> test_cmp_args () {
> echo "$1" >expect &&
> echo "$1" >actual &&
> test_cmp expect actual
> }
>
> to let these remain one-liners like:
>
> test_cmp_args "$(git rev-parse start)" "$(git rev-parse final^1^1^1)"
This idea come up before, but there is one flaw which makes this
function less useful: a non-zero exit code of the commands in the
command substitutions would be lost.
http://thread.gmane.org/gmane.comp.version-control.git/226699/focus=227361
Best,
Gábor
--
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
Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
On Mon, Sep 02, 2013 at 01:30:38AM -0500, Felipe Contreras wrote:
> Just as 5 == X is weird, so is comparing first the expected value, and
> then the value we are testing. So switch them around.
Actually, our normal comparison order for test output is "test_cmp
expect actual", as it shows a test failure as a diff with the expected
output as the base (i.e., the diff shows what went wrong).
That reasoning does not apply to "test a = b", which shows no output at
all. However, if you want to clean up and modernize these tests, it
would probably be better to simply convert them to use test_cmp.
I wonder if we should have a:
test_cmp_args () {
echo "$1" >expect &&
echo "$1" >actual &&
test_cmp expect actual
}
to let these remain one-liners like:
test_cmp_args "$(git rev-parse start)" "$(git rev-parse final^1^1^1)"
-Peff
--
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
