Re: [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value

[Junio C Hamano]

Stefan Beller  writes:

> On Tue, Jul 18, 2017 at 12:17 PM, Junio C Hamano  wrote:
>> Stefan Beller  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.

Re: [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value

[Stefan Beller]

On Tue, Jul 18, 2017 at 12:17 PM, Junio C Hamano  wrote:
> Stefan Beller  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?

Re: [PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value

[Junio C Hamano]

Stefan Beller  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 
> ---
>  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 < +$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-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-time 1112912053
>  author-tz -0700
> @@ -48,8 +50,8 @@ committer-mail 
>  committer-time 1112912053
>  committer-tz -0700
>  summary two
> -previous baf5e0b3869e0b2b2beb395a3720c7b51eac94fc file
> -filename file'
> +previous $ID1 file
> +filename file"
>  
>  cat >expect <  $ID1 1 1 1

[PATCH] t8008: rely on rev-parse'd HEAD instead of sha1 value

[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 
---
 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 expect <