From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "John Keeping" <john@keeping.me.uk>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"SZEDER Gábor" <szeder@ira.uka.de>,
"Felipe Contreras" <felipe.contreras@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions
Date: Wed, 04 Sep 2013 12:14:30 -0700 [thread overview]
Message-ID: <xmqqob88mmax.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20130904183559.GA3465@sigill.intra.peff.net> (Jeff King's message of "Wed, 4 Sep 2013 14:36:00 -0400")
Jeff King <peff@peff.net> 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.
next prev parent reply other threads:[~2013-09-04 19:14 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-02 6:30 [PATCH 0/4] t: rev-parse-parents: cleanups Felipe Contreras
2013-09-02 6:30 ` [PATCH 1/4] t: rev-parse-parents: fix style Felipe Contreras
2013-09-02 6:30 ` [PATCH 2/4] t: rev-parse-parents: fix weird ! notation Felipe Contreras
2013-09-02 6:30 ` [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions Felipe Contreras
2013-09-03 7:12 ` Jeff King
2013-09-03 7:51 ` SZEDER Gábor
2013-09-03 8:03 ` Jeff King
2013-09-03 10:45 ` Felipe Contreras
2013-09-03 11:10 ` SZEDER Gábor
2013-09-03 13:39 ` Felipe Contreras
2013-09-03 15:08 ` SZEDER Gábor
2013-09-03 17:04 ` [PATCH 0/4] " Jonathan Nieder
2013-09-03 17:05 ` [PATCH 1/4] rev-parse test: modernize quoting and whitespace Jonathan Nieder
2013-09-03 17:06 ` [PATCH 2/4] rev-parse test: use test_must_fail, not "if <command>; then false; fi" Jonathan Nieder
2013-09-03 21:56 ` Felipe Contreras
2013-09-03 17:07 ` [PATCH 3/4] rev-parse test: use test_cmp instead of "test" builtin Jonathan Nieder
2013-09-03 20:01 ` Junio C Hamano
2013-09-04 4:28 ` Jonathan Nieder
2013-09-03 22:01 ` Felipe Contreras
2013-09-03 17:11 ` [PATCH 4/4] rev-parse test: use standard test functions for setup Jonathan Nieder
2013-09-03 17:15 ` [PATCH v2 " Jonathan Nieder
2013-09-03 17:20 ` [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions Jeff King
2013-09-03 21:53 ` Felipe Contreras
2013-09-04 16:47 ` Junio C Hamano
2013-09-04 17:13 ` John Keeping
2013-09-04 17:38 ` Junio C Hamano
2013-09-04 18:36 ` Jeff King
2013-09-04 19:14 ` Junio C Hamano [this message]
2013-09-08 3:11 ` Felipe Contreras
2013-09-08 4:06 ` Jeff King
2013-09-08 4:13 ` Felipe Contreras
2013-09-08 4:14 ` Felipe Contreras
2013-09-08 4:26 ` Jeff King
2013-09-08 4:52 ` Felipe Contreras
2013-09-08 5:02 ` Jeff King
2013-09-08 23:25 ` Felipe Contreras
2013-09-08 23:45 ` Jeff King
2013-09-09 0:45 ` Felipe Contreras
2013-09-08 18:33 ` Junio C Hamano
2013-09-08 23:18 ` Felipe Contreras
2013-09-08 8:11 ` Philip Oakley
2013-09-03 17:31 ` Junio C Hamano
2013-09-03 17:33 ` Junio C Hamano
2013-09-03 21:52 ` Felipe Contreras
2013-09-02 6:30 ` [PATCH 4/4] t: rev-parse-parents: simplify setup Felipe Contreras
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=xmqqob88mmax.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=john@keeping.me.uk \
--cc=jrnieder@gmail.com \
--cc=peff@peff.net \
--cc=szeder@ira.uka.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.