Alexey Shumkin <alex.crez...@gmail.com> writes:
> The expected SHA-1 digests are always available in variables. Use
> them instead of hardcoding.
>
> Signed-off-by: Alexey Shumkin <alex.crez...@gmail.com>
> ---
> t/t6006-rev-list-format.sh | 130
> +++++++++++++++++++++++++--------------------
> 1 file changed, 72 insertions(+), 58 deletions(-)
>
> diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
> index f94f0c4..c248509 100755
> --- a/t/t6006-rev-list-format.sh
> +++ b/t/t6006-rev-list-format.sh
> @@ -6,8 +6,19 @@ test_description='git rev-list --pretty=format test'
>
> test_tick
> test_expect_success 'setup' '
> -touch foo && git add foo && git commit -m "added foo" &&
> - echo changed >foo && git commit -a -m "changed foo"
> + touch foo &&
This is inherited from the original, but these days we try to avoid
touch, unless it is about setting a new file timestamp. The
canonical (in the script we write) way to create an empty file is:
: >foo
with or without ": ", it does not matter that much.
> + git add foo &&
> + git commit -m "added foo" &&
> + head1=$(git rev-parse --verify HEAD) &&
> + head1_7=$(echo $head1 | cut -c1-7) &&
Why do we want "whatever_7" variables and use "cut -c1-7" to produce
them? Is "7" something we care deeply about?
I think what we care a lot more than "7" that happens to be the
current default value is to make sure that, if we ever update the
default abbreviation length to a larger value, the abbreviation
shown with --format=%h is consistent with the abbreviation that is
given by rev-parse --short.
head1_short=$(git rev-parse --short $head1)
perhaps?
> + echo changed >foo &&
> + git commit -a -m "changed foo" &&
> + head2=$(git rev-parse --verify HEAD) &&
> + head2_7=$(echo $head2 | cut -c1-7) &&
> + head2_parent=$(git cat-file -p HEAD | grep parent | cut -f 2 -d" ") &&
Do not use "cat-file -p" that is for human consumption in scripts,
unless you are testing how the format for human consumption should
look like (we may later add more pretty-print to them), which is not
the case here.
Also be careful and pay attention to the end of the header; you do
not want to pick up a random "parent" string in the middle of a log
message.
head2_parent=$(git cat-file commit HEAD | sed -n -e "s/^parent //p" -e
"/^$/q")
would be much better.
> + head2_parent_7=$(echo $head2_parent | cut -c1-7) &&
> + tree2=$(git cat-file -p HEAD | grep tree | cut -f 2 -d" ") &&
Likewise.
> + tree2_7=$(echo $tree2 | cut -c1-7)
Likewise.
> @@ -131,39 +142,42 @@ This commit message is much longer than the others,
> and it will be encoded in iso8859-1. We should therefore
> include an iso8859 character: ¡bueno!
> EOF
> +
> test_expect_success 'setup complex body' '
> -git config i18n.commitencoding iso8859-1 &&
> - echo change2 >foo && git commit -a -F commit-msg
> + git config i18n.commitencoding iso8859-1 &&
> + echo change2 >foo && git commit -a -F commit-msg &&
> + head3=$(git rev-parse --verify HEAD) &&
> + head3_7=$(echo $head3 | cut -c1-7)
> '
Likewise.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
