* [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value
@ 2017-07-18 0:20 Stefan Beller
2017-07-18 19:17 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Beller @ 2017-07-18 0:20 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
Remove hard coded sha1 values, obtain the values using 'git rev-parse HEAD'
which should be future proof regardless of the hash function used.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
t/t8008-blame-formats.sh | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/t/t8008-blame-formats.sh b/t/t8008-blame-formats.sh
index 92c8e792d1..49cac4b9af 100755
--- a/t/t8008-blame-formats.sh
+++ b/t/t8008-blame-formats.sh
@@ -12,22 +12,25 @@ test_expect_success 'setup' '
echo c >>file &&
echo d >>file &&
test_tick &&
- git commit -a -m two
+ git commit -a -m two &&
+ ID1=$(git rev-parse HEAD^) &&
+ shortID1="^$(git rev-parse HEAD^ |cut -c 1-7)" &&
+ ID2=$(git rev-parse HEAD) &&
+ shortID2="$(git rev-parse HEAD |cut -c 1-8)"
'
-cat >expect <<'EOF'
-^baf5e0b (A U Thor 2005-04-07 15:13:13 -0700 1) a
-8825379d (A U Thor 2005-04-07 15:14:13 -0700 2) b
-8825379d (A U Thor 2005-04-07 15:14:13 -0700 3) c
-8825379d (A U Thor 2005-04-07 15:14:13 -0700 4) d
+cat >expect <<EOF
+$shortID1 (A U Thor 2005-04-07 15:13:13 -0700 1) a
+$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 2) b
+$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 3) c
+$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 4) d
EOF
test_expect_success 'normal blame output' '
git blame file >actual &&
test_cmp expect actual
'
-ID1=baf5e0b3869e0b2b2beb395a3720c7b51eac94fc
-COMMIT1='author A U Thor
+COMMIT1="author A U Thor
author-mail <author@example.com>
author-time 1112911993
author-tz -0700
@@ -37,9 +40,8 @@ committer-time 1112911993
committer-tz -0700
summary one
boundary
-filename file'
-ID2=8825379dfb8a1267b58e8e5bcf69eec838f685ec
-COMMIT2='author A U Thor
+filename file"
+COMMIT2="author A U Thor
author-mail <author@example.com>
author-time 1112912053
author-tz -0700
@@ -48,8 +50,8 @@ committer-mail <committer@example.com>
committer-time 1112912053
committer-tz -0700
summary two
-previous baf5e0b3869e0b2b2beb395a3720c7b51eac94fc file
-filename file'
+previous $ID1 file
+filename file"
cat >expect <<EOF
$ID1 1 1 1
--
2.13.3.650.g5ebc568d5d
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value
2017-07-18 0:20 [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value Stefan Beller
@ 2017-07-18 19:17 ` Junio C Hamano
2017-07-18 19:22 ` Stefan Beller
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2017-07-18 19:17 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
Stefan Beller <sbeller@google.com> writes:
> Remove hard coded sha1 values, obtain the values using 'git rev-parse HEAD'
> which should be future proof regardless of the hash function used.
Don't hardcoded lengths of the hashes defeat this future-proofing
effort, though? It shouldn't be too hard to do the equivalent of
the auto computation of abbreviation in this script, which would be
true future-proofing, I guess.
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> t/t8008-blame-formats.sh | 28 +++++++++++++++-------------
> 1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/t/t8008-blame-formats.sh b/t/t8008-blame-formats.sh
> index 92c8e792d1..49cac4b9af 100755
> --- a/t/t8008-blame-formats.sh
> +++ b/t/t8008-blame-formats.sh
> @@ -12,22 +12,25 @@ test_expect_success 'setup' '
> echo c >>file &&
> echo d >>file &&
> test_tick &&
> - git commit -a -m two
> + git commit -a -m two &&
> + ID1=$(git rev-parse HEAD^) &&
> + shortID1="^$(git rev-parse HEAD^ |cut -c 1-7)" &&
> + ID2=$(git rev-parse HEAD) &&
> + shortID2="$(git rev-parse HEAD |cut -c 1-8)"
> '
>
> -cat >expect <<'EOF'
> -^baf5e0b (A U Thor 2005-04-07 15:13:13 -0700 1) a
> -8825379d (A U Thor 2005-04-07 15:14:13 -0700 2) b
> -8825379d (A U Thor 2005-04-07 15:14:13 -0700 3) c
> -8825379d (A U Thor 2005-04-07 15:14:13 -0700 4) d
> +cat >expect <<EOF
> +$shortID1 (A U Thor 2005-04-07 15:13:13 -0700 1) a
> +$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 2) b
> +$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 3) c
> +$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 4) d
> EOF
> test_expect_success 'normal blame output' '
> git blame file >actual &&
> test_cmp expect actual
> '
>
> -ID1=baf5e0b3869e0b2b2beb395a3720c7b51eac94fc
> -COMMIT1='author A U Thor
> +COMMIT1="author A U Thor
> author-mail <author@example.com>
> author-time 1112911993
> author-tz -0700
> @@ -37,9 +40,8 @@ committer-time 1112911993
> committer-tz -0700
> summary one
> boundary
> -filename file'
> -ID2=8825379dfb8a1267b58e8e5bcf69eec838f685ec
> -COMMIT2='author A U Thor
> +filename file"
> +COMMIT2="author A U Thor
> author-mail <author@example.com>
> author-time 1112912053
> author-tz -0700
> @@ -48,8 +50,8 @@ committer-mail <committer@example.com>
> committer-time 1112912053
> committer-tz -0700
> summary two
> -previous baf5e0b3869e0b2b2beb395a3720c7b51eac94fc file
> -filename file'
> +previous $ID1 file
> +filename file"
>
> cat >expect <<EOF
> $ID1 1 1 1
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value
2017-07-18 19:17 ` Junio C Hamano
@ 2017-07-18 19:22 ` Stefan Beller
2017-07-18 19:38 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Beller @ 2017-07-18 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Tue, Jul 18, 2017 at 12:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> Remove hard coded sha1 values, obtain the values using 'git rev-parse HEAD'
>> which should be future proof regardless of the hash function used.
>
> Don't hardcoded lengths of the hashes defeat this future-proofing
> effort, though? It shouldn't be too hard to do the equivalent of
> the auto computation of abbreviation in this script, which would be
> true future-proofing, I guess.
It depends on the definition of future proofing.
My definition here only included the change of the hash function,
not the change of display length in git-blame for a small artificial repo
with 2 commits . These seem to be unrelated, so in case we'd change
the length of the abbreviated displayed hash, we'd still want to have
a test to tell us?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value
2017-07-18 19:22 ` Stefan Beller
@ 2017-07-18 19:38 ` Junio C Hamano
2017-07-26 19:06 ` [PATCHv2] " Stefan Beller
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2017-07-18 19:38 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
Stefan Beller <sbeller@google.com> writes:
> On Tue, Jul 18, 2017 at 12:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Stefan Beller <sbeller@google.com> writes:
>>
>>> Remove hard coded sha1 values, obtain the values using 'git rev-parse HEAD'
>>> which should be future proof regardless of the hash function used.
>>
>> Don't hardcoded lengths of the hashes defeat this future-proofing
>> effort, though? It shouldn't be too hard to do the equivalent of
>> the auto computation of abbreviation in this script, which would be
>> true future-proofing, I guess.
>
> It depends on the definition of future proofing.
> My definition here only included the change of the hash function,
> not the change of display length in git-blame for a small artificial repo
> with 2 commits . These seem to be unrelated, so in case we'd change
> the length of the abbreviated displayed hash, we'd still want to have
> a test to tell us?
The thing is that depending on how these 2 commits hash and share
prefixes, the length needed to disambiguate changes.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCHv2] t8008: rely on rev-parse'd HEAD instead of sha1 value
2017-07-18 19:38 ` Junio C Hamano
@ 2017-07-26 19:06 ` Stefan Beller
2017-07-26 20:32 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Beller @ 2017-07-26 19:06 UTC (permalink / raw)
To: gitster; +Cc: git, sbeller
Remove hard coded sha1 values, obtain the values using
'git rev-parse HEAD' which should be future proof regardless
of the hash function used.
Additionally future-proof the test by hard coding the
abbreviation length of the hash.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
> Don't hardcoded lengths of the hashes defeat this future-proofing
> effort, though? It shouldn't be too hard to do the equivalent of
> the auto computation of abbreviation in this script, which would be
> true future-proofing, I guess.
Added --abbrev=n to also hard code hash abbreviation. At first
I had the impression of a off-by-one-error, but after reading the
man page for both blame and rev-parse, I realize that blames
abbrev notion is different than rev-parse precisely for the
caret that may occur to indicate out-of-range.
t/t8008-blame-formats.sh | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/t/t8008-blame-formats.sh b/t/t8008-blame-formats.sh
index 92c8e792d1..ae4b579d24 100755
--- a/t/t8008-blame-formats.sh
+++ b/t/t8008-blame-formats.sh
@@ -12,22 +12,25 @@ test_expect_success 'setup' '
echo c >>file &&
echo d >>file &&
test_tick &&
- git commit -a -m two
+ git commit -a -m two &&
+ ID1=$(git rev-parse HEAD^) &&
+ shortID1="^$(git rev-parse HEAD^ |cut -c 1-17)" &&
+ ID2=$(git rev-parse HEAD) &&
+ shortID2="$(git rev-parse HEAD |cut -c 1-18)"
'
-cat >expect <<'EOF'
-^baf5e0b (A U Thor 2005-04-07 15:13:13 -0700 1) a
-8825379d (A U Thor 2005-04-07 15:14:13 -0700 2) b
-8825379d (A U Thor 2005-04-07 15:14:13 -0700 3) c
-8825379d (A U Thor 2005-04-07 15:14:13 -0700 4) d
+cat >expect <<EOF
+$shortID1 (A U Thor 2005-04-07 15:13:13 -0700 1) a
+$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 2) b
+$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 3) c
+$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 4) d
EOF
test_expect_success 'normal blame output' '
- git blame file >actual &&
+ git blame --abbrev=17 file >actual &&
test_cmp expect actual
'
-ID1=baf5e0b3869e0b2b2beb395a3720c7b51eac94fc
-COMMIT1='author A U Thor
+COMMIT1="author A U Thor
author-mail <author@example.com>
author-time 1112911993
author-tz -0700
@@ -37,9 +40,8 @@ committer-time 1112911993
committer-tz -0700
summary one
boundary
-filename file'
-ID2=8825379dfb8a1267b58e8e5bcf69eec838f685ec
-COMMIT2='author A U Thor
+filename file"
+COMMIT2="author A U Thor
author-mail <author@example.com>
author-time 1112912053
author-tz -0700
@@ -48,8 +50,8 @@ committer-mail <committer@example.com>
committer-time 1112912053
committer-tz -0700
summary two
-previous baf5e0b3869e0b2b2beb395a3720c7b51eac94fc file
-filename file'
+previous $ID1 file
+filename file"
cat >expect <<EOF
$ID1 1 1 1
--
2.14.0.rc0.3.g6c2e499285
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCHv2] t8008: rely on rev-parse'd HEAD instead of sha1 value
2017-07-26 19:06 ` [PATCHv2] " Stefan Beller
@ 2017-07-26 20:32 ` Junio C Hamano
0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2017-07-26 20:32 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
Stefan Beller <sbeller@google.com> writes:
> Remove hard coded sha1 values, obtain the values using
> 'git rev-parse HEAD' which should be future proof regardless
> of the hash function used.
>
> Additionally future-proof the test by hard coding the
> abbreviation length of the hash.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>
>> Don't hardcoded lengths of the hashes defeat this future-proofing
>> effort, though? It shouldn't be too hard to do the equivalent of
>> the auto computation of abbreviation in this script, which would be
>> true future-proofing, I guess.
>
> Added --abbrev=n to also hard code hash abbreviation. At first
> I had the impression of a off-by-one-error, but after reading the
> man page for both blame and rev-parse, I realize that blames
> abbrev notion is different than rev-parse precisely for the
> caret that may occur to indicate out-of-range.
OK, and 17 hexdigits ought to be sufficient for a sample repository
we create for the test---we shouldn't be picking a hash that would
cause hash prefix collisions with such a small number of objects and
reasonably long prefix anyway ;-)
Thanks, will queue.
>
> t/t8008-blame-formats.sh | 30 ++++++++++++++++--------------
> 1 file changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/t/t8008-blame-formats.sh b/t/t8008-blame-formats.sh
> index 92c8e792d1..ae4b579d24 100755
> --- a/t/t8008-blame-formats.sh
> +++ b/t/t8008-blame-formats.sh
> @@ -12,22 +12,25 @@ test_expect_success 'setup' '
> echo c >>file &&
> echo d >>file &&
> test_tick &&
> - git commit -a -m two
> + git commit -a -m two &&
> + ID1=$(git rev-parse HEAD^) &&
> + shortID1="^$(git rev-parse HEAD^ |cut -c 1-17)" &&
> + ID2=$(git rev-parse HEAD) &&
> + shortID2="$(git rev-parse HEAD |cut -c 1-18)"
> '
>
> -cat >expect <<'EOF'
> -^baf5e0b (A U Thor 2005-04-07 15:13:13 -0700 1) a
> -8825379d (A U Thor 2005-04-07 15:14:13 -0700 2) b
> -8825379d (A U Thor 2005-04-07 15:14:13 -0700 3) c
> -8825379d (A U Thor 2005-04-07 15:14:13 -0700 4) d
> +cat >expect <<EOF
> +$shortID1 (A U Thor 2005-04-07 15:13:13 -0700 1) a
> +$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 2) b
> +$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 3) c
> +$shortID2 (A U Thor 2005-04-07 15:14:13 -0700 4) d
> EOF
> test_expect_success 'normal blame output' '
> - git blame file >actual &&
> + git blame --abbrev=17 file >actual &&
> test_cmp expect actual
> '
>
> -ID1=baf5e0b3869e0b2b2beb395a3720c7b51eac94fc
> -COMMIT1='author A U Thor
> +COMMIT1="author A U Thor
> author-mail <author@example.com>
> author-time 1112911993
> author-tz -0700
> @@ -37,9 +40,8 @@ committer-time 1112911993
> committer-tz -0700
> summary one
> boundary
> -filename file'
> -ID2=8825379dfb8a1267b58e8e5bcf69eec838f685ec
> -COMMIT2='author A U Thor
> +filename file"
> +COMMIT2="author A U Thor
> author-mail <author@example.com>
> author-time 1112912053
> author-tz -0700
> @@ -48,8 +50,8 @@ committer-mail <committer@example.com>
> committer-time 1112912053
> committer-tz -0700
> summary two
> -previous baf5e0b3869e0b2b2beb395a3720c7b51eac94fc file
> -filename file'
> +previous $ID1 file
> +filename file"
>
> cat >expect <<EOF
> $ID1 1 1 1
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-07-26 20:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-18 0:20 [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value Stefan Beller
2017-07-18 19:17 ` Junio C Hamano
2017-07-18 19:22 ` Stefan Beller
2017-07-18 19:38 ` Junio C Hamano
2017-07-26 19:06 ` [PATCHv2] " Stefan Beller
2017-07-26 20:32 ` Junio C Hamano
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.