Re: [PATCH] t/: work around one-shot variable assignment with test_must_fail

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

2010/7/21 Brandon Casey <casey@xxxxxxxxxxxxxxx>:
> On 07/20/2010 06:19 PM, Erick Mattos wrote:
>> 2010/7/20 Brandon Casey <casey@xxxxxxxxxxxxxxx>
>>> No time to investigate, but here is an example patch and the
>>> results of running the affected tests.
>
>> You have made cosmetic changes which do not do the same as the original.
>?
> Nope, look closer.  The changes are not cosmetic.

Now I see it.  I was not completely aware of the problem, only of your
email.  Maybe I should subscribe to the list at last... ;-D

> Try this:
>
>   run_it () { "$@"; }; run_it foo= true && echo success || echo failure
>
> You probably get something like this (if you're using bash):
>
>   bash: foo=: command not found

It would work if it was like:

run_it () { eval "$@"; }; run_it "foo= true" && echo success || echo failure

But I think your approach is better shaped for a fast solution.

> That's because the one-shot variable assignment doesn't work when
> used like this.  It also means that the original tests which do:
>
>   test_must_fail PAGER= git ...
>
> are broken.  We ran into this problem a while back and fixed it in
> the commit that I referenced (e2007832).  I fixed the new instances
> in t2017, t3200, and t3301 in the patch that I sent.
>
> For the tests in t2017 and t3200 that now fail, the originals seem to
> expect 'git reflog show' to return non-zero when asked to show the reflog
> for a ref which doesn't have a log.  reflog does not currently return
> non-zero in this case.  Either the tests should be updated to reflect
> the actual behavior of 'reflog show', or 'reflog show' should be updated
> to return non-zero when passed a ref without a log.

So fixing it is a need.

On t2017 and t3200 the problem that appeared was because no message
and error had been generated when there is no reflog.  Git reflog when
run on a ref with a nonexistent reflog file exits with 0 saying
nothing.

I don't see this as a correct behavior but as those tests were just to
enforce the previous "! test -f..." test which is already enough for
checking the intended behavior then I would think it was good enough
just to wipe out the "problematic git reflog" commands until deciding
how quiet git reflog command should be when there is no reflog file to
show.

Although I just realized Junio sent an email following this thread and
I bet he could give a better solution or his directions.  Going to
read it now.

Thanks for your clarifications.

Regards
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]