On Mon, May 09, 2016 at 11:36:09AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Yes, I think the comment should just go. Nobody used that alphabet
> > form since it was written in d17cf5f3 (tests: Introduce test_seq,
> > 2012-08-04).
> >
> >> I don't really care either way whethe
On Mon, May 9, 2016 at 5:08 PM, Junio C Hamano wrote:
> Subject: [PATCH] test-lib-functions.sh: rewrite test_seq without Perl
>
> Rewrite the 'seq' imitation only with commands and features
> that are typically found as built-in in modern POSIX shells,
> instead of relying on Perl to run a single-
Junio C Hamano writes:
> Stop promising that we may allow using "letters"; this would open an
> easier reimplementation that does not rely on $PERL, if somebody
> later wants to.
>
> Signed-off-by: Junio C Hamano
And I am not the one who particularly wants to, but here is the
previous patch sen
On Mon, May 9, 2016 at 2:36 PM, Junio C Hamano wrote:
> Subject: test-lib-functions.sh: remove misleading comment on test_seq
>
> We never used the "letters" form since we came up with "test_seq" to
> replace use of non-portable "seq" in our test script, which we
> introduced it at d17cf5f3 (tests
Junio C Hamano writes:
> Yes, I think the comment should just go. Nobody used that alphabet
> form since it was written in d17cf5f3 (tests: Introduce test_seq,
> 2012-08-04).
>
>> I don't really care either way whether it is replaced or not (at one
>> point there were some people really interest
Jeff King writes:
> On Mon, May 09, 2016 at 12:02:45PM -0400, Eric Sunshine wrote:
>
>> > I had that thought, too, but I think it would be an error to do so.
>> > test_seq is supposed to be a replacement for "seq", which does not
>> > understand non-numeric sequences.
>>
>> Although, the comment
ast have the decency to make it more
>> readable by doing something like:
>>
>> printf "%s\n" 1 2 3 4 5 6 7 8 9 10
>>
>> ;-)
>>
>> But as I said, as a response to "t6044 broken on pu" bug report,
>> s/seq/test_seq/ is the only s
On Mon, May 09, 2016 at 12:02:45PM -0400, Eric Sunshine wrote:
> > I had that thought, too, but I think it would be an error to do so.
> > test_seq is supposed to be a replacement for "seq", which does not
> > understand non-numeric sequences.
>
> Although, the comment block just above test_seq()
On Mon, May 9, 2016 at 4:33 AM, Jeff King wrote:
> On Mon, May 09, 2016 at 08:30:51AM +0200, demerphq wrote:
>> > - perl -le 'print for $ARGV[0]..$ARGV[1]' -- "$@"
>> > + test_seq_counter__=$1
>> > + while test "$test_seq_counter__" -le $2
>> > + do
>> > + ech
On Mon, May 09, 2016 at 08:30:51AM +0200, demerphq wrote:
> > - perl -le 'print for $ARGV[0]..$ARGV[1]' -- "$@"
> > + test_seq_counter__=$1
> > + while test "$test_seq_counter__" -le $2
> > + do
> > + echo "$test_seq_counter__"
> > + test_seq_cou
doing something like:
>
> printf "%s\n" 1 2 3 4 5 6 7 8 9 10
>
> ;-)
>
> But as I said, as a response to "t6044 broken on pu" bug report,
> s/seq/test_seq/ is the only sensible change.
>
> Improving "test_seq, the alternative to seq" is
ething like:
>
> printf "%s\n" 1 2 3 4 5 6 7 8 9 10
>
> ;-)
>
> But as I said, as a response to "t6044 broken on pu" bug report,
> s/seq/test_seq/ is the only sensible change.
>
> Improving "test_seq, the alternative to seq" is a
But as I said, as a response to "t6044 broken on pu" bug report,
s/seq/test_seq/ is the only sensible change.
Improving "test_seq, the alternative to seq" is a separate topic.
If you have aversion to $PERL, perhaps do them without using
anything what is not expected to be built-
On 08.05.16 04:21, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> That's true, but the test passes anyway.
> You can also remove the body of the test and replace it with "true"
> and say "the test passes anyway". Changing the test to use a file
> with only one line is irresponsible, if
Torsten Bögershausen writes:
> That's true, but the test passes anyway.
You can also remove the body of the test and replace it with "true"
and say "the test passes anyway". Changing the test to use a file
with only one line is irresponsible, if you do not know the nature
of expected future bug
On 2016-05-07 14.19, Andreas Schwab wrote:
> Torsten Bögershausen writes:
>
>> The "seq" is not understood by all shells,
>> using printf fixes this,
>>
>> index 20a3ffe..48d964e 100755
>> --- a/t/t6044-merge-unrelated-index-changes.sh
>> +++ b/t/t6044-merge-unrelated-index-changes.sh
>> @@ -20,7
On 07/05/16 14:15, Ramsay Jones wrote:
>
>
> On 07/05/16 13:19, Andreas Schwab wrote:
>> Torsten Bögershausen writes:
>>
>>> The "seq" is not understood by all shells,
>>> using printf fixes this,
>>>
>>> index 20a3ffe..48d964e 100755
>>> --- a/t/t6044-merge-unrelated-index-changes.sh
>>> +++
On 07/05/16 13:19, Andreas Schwab wrote:
> Torsten Bögershausen writes:
>
>> The "seq" is not understood by all shells,
>> using printf fixes this,
>>
>> index 20a3ffe..48d964e 100755
>> --- a/t/t6044-merge-unrelated-index-changes.sh
>> +++ b/t/t6044-merge-unrelated-index-changes.sh
>> @@ -20,7
Torsten Bögershausen writes:
> The "seq" is not understood by all shells,
> using printf fixes this,
>
> index 20a3ffe..48d964e 100755
> --- a/t/t6044-merge-unrelated-index-changes.sh
> +++ b/t/t6044-merge-unrelated-index-changes.sh
> @@ -20,7 +20,7 @@ test_description="merges with unrelated inde
The "seq" is not understood by all shells,
using printf fixes this,
index 20a3ffe..48d964e 100755
--- a/t/t6044-merge-unrelated-index-changes.sh
+++ b/t/t6044-merge-unrelated-index-changes.sh
@@ -20,7 +20,7 @@ test_description="merges with unrelated index changes"
# Commit E: renames a->subdir/
20 matches
Mail list logo
