On Wednesday, January 2, 2019 11:15:02 AM MST Junio C Hamano wrote:
> 'date +%s' is used everywhere in this patch but has never been used
> in our test suite before. It is not portable.
So I don't make this mistake again, Is there a reference somewhere for that is
and is not portable?
>
> We perhaps can use "test-tool date timestamp", like so
>
> check_human_date $(test-tool date timestamp "18000 seconds ago") ...
>
> or moving the part that munges 18000 into the above form inside
> check_human_date helper function, e.g.
>
> check_human_date () {
> commit_date=$(test-tool date timestamp "$1 seconds ago")
> commit_date="$commit_date +0200"
> expect=$2
> ...
> }
>
> which would let us write
>
> check_human_date 432000" $THIS_YEAR_REGEX # 5 days ago
Thanks
>
> > +check_human_date() {
> > + commit_date=$1
> > + expect=$2
> > + test_expect_success "$commit_date" "
> > + echo $expect $commit_date >dates &&
> > + git add dates &&
> > + git commit -m 'Expect String' --date=\"$commit_date\" dates &&
> > + git log -1 --date=human | grep \"^Date:\" >actual &&
> > + grep \"$expect\" actual
> > +"
>
> As the body of the test_expect_success helper is eval'ed, variables
> $commit_date and $expect should be visible to it, without turning
> them into values before executing test_expect_success function,
> i.e.
>
> test_expect_success "$commit_date" '
> echo "$expect $commit_date" >dates &&
> ...
> git commit -m "Expect String" --date="$commit_date" dates &&
> git show -s --date=human | grep '^Date:" >actual &&
> grep "$expect" actual
> '
>
> which would reduce the need for unreadable backslashes.
I was worried about embedded spaces that might not be parsed correctly by the
called function. I will update
>
> Instead of duplicating, perhaps move this to a more common place?
> Would it make sense to make it "check_date_format ()" helper by
> passing another argument to parameterize --date=human part
I had considered that, but then noted that for the other formats specific
strings were being used. The use of specific strings was possible since the
other formats were always guarenteed to have the same string literal due to a
singe unvarying input.
I don't mind parameterize the format and it would make the solution more
general.
> > "Stephen P. Smith" <ischis2@xxxxxxx> writes:
> > +# Subtract some known constant time and look for expected field format
> > +TODAY_REGEX='5 hours ago'
> > +THIS_YEAR_REGEX='[A-Z][a-z][a-z] [A-Z][a-z][a-z] [0-9]*
> > [012][0-9]:[0-6][0-9]' +MORE_THAN_A_YEAR_REGEX='[A-Z][a-z][a-z]
> > [A-Z][a-z][a-z] [0-9]* [0-9][0-9][0-9][0-9]' +check_human_date "$(($(date
> > +%s)-18000)) +0200" $TODAY_REGEX # 5 hours ago +check_human_date
> > "$(($(date +%s)-432000)) +0200" $THIS_YEAR_REGEX # 5 days ago
> > +check_human_date() {
> > + commit_date=$1
> > + expect=$2
> > + test_expect_success "$commit_date" "
> > + echo $expect $commit_date >dates &&
> > + git add dates &&
> > + git commit -m 'Expect String' --date=\"$commit_date\" dates &&
> > + git show --date=human | grep \"^Date:\" >actual &&
>
> Using "show" here is much better than "log -1" above; using "show
> -s" would be even better.
I was attempting to test both git log and git show. For get log the `-1` was
to only get the latest commit.
Are you suggesting that t4202-log.sh not be updated and that only and t7007-
show.sh and t0006-date.sh updated?
Side note: I found when updating that all three scripts that log and show
returned the same formats, but date returned a different string if the delta
date was less than 24hours
I just noted that the patch 3/3 should be re-titled since the tests are
currently for three commands.
Hope you are better.
sps
