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 <szeder@xxxxxxxxxx> 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 <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html