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

2 messages, 2 authors, 2017-07-18 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2017-07-18 19:17:38

Stefan Beller [off-list ref] 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.
quoted hunk
Signed-off-by: Stefan Beller <redacted>
---
 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

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

From: Stefan Beller <hidden>
Date: 2017-07-18 19:22:43

On Tue, Jul 18, 2017 at 12:17 PM, Junio C Hamano [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help