Re: [PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
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. Ok! + 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 did not spend too much time to think of names of variables at the moment I was writing this code ) 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? It's an inherited code from 1.5 years ago Git ;) taken from some other tests I'll change it as you propose ) + 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. yep! you're definitely right + 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
Re: [PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
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. but is there git something to return abbreviated tree hash except pretty formats that is implicitly tested here? -- 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
Re: [PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
Alexey Shumkin alex.crez...@gmail.com writes: 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? ... Likewise. + tree2_7=$(echo $tree2 | cut -c1-7) Likewise. but is there git something to return abbreviated tree hash except pretty formats that is implicitly tested here? Does git rev-parse --short $tree2 count? -- 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
Re: [PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
Alexey Shumkin alex.crez...@gmail.com writes: 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? ... Likewise. +tree2_7=$(echo $tree2 | cut -c1-7) Likewise. but is there git something to return abbreviated tree hash except pretty formats that is implicitly tested here? Does git rev-parse --short $tree2 count? Oops! Yep! -- 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
[PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
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 + git add foo + git commit -m added foo + head1=$(git rev-parse --verify HEAD) + head1_7=$(echo $head1 | cut -c1-7) + 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 ) + head2_parent_7=$(echo $head2_parent | cut -c1-7) + tree2=$(git cat-file -p HEAD | grep tree | cut -f 2 -d ) + tree2_7=$(echo $tree2 | cut -c1-7) ' # usage: test_format name format_string expected_output @@ -19,49 +30,49 @@ test_cmp expect.$1 output.$1 } -test_format percent %%h 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d +test_format percent %%h EOF +commit $head2 %h -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 +commit $head1 %h EOF -test_format hash %H%n%h 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d -131a310eb913d107dd3c09a65d1651175898735d -131a310 -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 -86c75cfd708a0e5868dc876ed5b8bb66c80b4873 -86c75cf +test_format hash %H%n%h EOF +commit $head2 +$head2 +$head2_7 +commit $head1 +$head1 +$head1_7 EOF -test_format tree %T%n%t 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d -fe722612f26da5064c32ca3843aa154bdb0b08a0 -fe72261 -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 +test_format tree %T%n%t EOF +commit $head2 +$tree2 +$tree2_7 +commit $head1 4d5fcadc293a348e88f777dc0920f11e7d71441c 4d5fcad EOF -test_format parents %P%n%p 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d -86c75cfd708a0e5868dc876ed5b8bb66c80b4873 -86c75cf -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 +test_format parents %P%n%p EOF +commit $head2 +$head1 +$head2_parent_7 +commit $head1 EOF # we don't test relative here -test_format author %an%n%ae%n%ad%n%aD%n%at 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d +test_format author %an%n%ae%n%ad%n%aD%n%at EOF +commit $head2 A U Thor aut...@example.com Thu Apr 7 15:13:13 2005 -0700 Thu, 7 Apr 2005 15:13:13 -0700 1112911993 -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 +commit $head1 A U Thor aut...@example.com Thu Apr 7 15:13:13 2005 -0700 @@ -69,14 +80,14 @@ Thu, 7 Apr 2005 15:13:13 -0700 1112911993 EOF -test_format committer %cn%n%ce%n%cd%n%cD%n%ct 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d +test_format committer %cn%n%ce%n%cd%n%cD%n%ct EOF +commit $head2 C O Mitter commit...@example.com Thu Apr 7 15:13:13 2005 -0700 Thu, 7 Apr 2005 15:13:13 -0700 1112911993 -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 +commit $head1 C O Mitter commit...@example.com Thu Apr 7 15:13:13 2005 -0700 @@ -84,21 +95,21 @@ Thu, 7 Apr 2005 15:13:13 -0700 1112911993 EOF -test_format encoding %e 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 +test_format encoding %e EOF +commit $head2 +commit $head1 EOF -test_format subject %s 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d +test_format subject %s EOF +commit $head2 changed foo -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 +commit $head1 added foo EOF -test_format body %b 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 +test_format body %b EOF +commit $head2 +commit $head1 EOF test_format raw-body %B 'EOF' @@ -110,17 +121,17 @@ added foo EOF -test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d +test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy EOF +commit $head2 [31mfoo[32mbar[34mbaz[mxyzzy -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 +commit $head1 [31mfoo[32mbar[34mbaz[mxyzzy EOF -test_format advanced-colors '%C(red yellow bold)foo%C(reset)' 'EOF' -commit 131a310eb913d107dd3c09a65d1651175898735d +test_format advanced-colors '%C(red yellow bold)foo%C(reset)' EOF +commit $head2 [1;31;43mfoo[m -commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873 +commit $head1 [1;31;43mfoo[m EOF @@ -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
Re: [PATCH v4 1/4] t6006 (rev-list-format): don't hardcode SHA-1 in expected outputs
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
