All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: git@vger.kernel.org
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Eli Schwartz" <eschwartz93@gmail.com>,
	"René Scharfe" <l.s.r@web.de>,
	"brian m . carlson" <sandals@crustytoothpaste.net>,
	"Konstantin Ryabitsev" <konstantin@linuxfoundation.org>,
	"Michal Suchánek" <msuchanek@suse.de>,
	"Raymond E . Pasco" <ray@ameretat.dev>,
	demerphq <demerphq@gmail.com>, "Theodore Ts'o" <tytso@mit.edu>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: [PATCH 8/9] archive tests: test for "gzip -cn" and "git archive gzip" stability
Date: Thu,  2 Feb 2023 10:32:28 +0100	[thread overview]
Message-ID: <patch-8.9-62c796da4e2-20230202T093212Z-avarab@gmail.com> (raw)
In-Reply-To: <cover-0.9-00000000000-20230202T093212Z-avarab@gmail.com>

If our test suite is instrumented to run the first "test_cmp_bin" in
"test_done" it'll mostly pass, but fail on a few tests, such as
"t5319-multi-pack-index.sh". Those tests reveal edge cases where the
output of "gzip -cn" is different than that of "git archive gzip" for
the same input.

Let's extract a minimal version of the part of
"t5319-multi-pack-index.sh" which triggers it, and add a test for
archival stability.

Whatever we ultimately decide to promise when it comes to this
stability (see [1]) it'll be better to go into any behavior difference
knowing that's what we're about to do, rather than discover widespread
breakage due to already released Git versions.

The "GZIP_TRIVIALLY_STABLE" code here is added because on OSX even a
trivial *.tgz generated by the two methods will be different.

1. https://lore.kernel.org/git/a812a664-67ea-c0ba-599f-cb79e2d96694@gmail.com/

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 t/t5005-archive-stability.sh | 70 ++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100755 t/t5005-archive-stability.sh

diff --git a/t/t5005-archive-stability.sh b/t/t5005-archive-stability.sh
new file mode 100755
index 00000000000..c7532886920
--- /dev/null
+++ b/t/t5005-archive-stability.sh
@@ -0,0 +1,70 @@
+#!/bin/sh
+
+test_description='git archive stabilty'
+
+TEST_PASSES_SANITIZE_LEAK=true
+. ./test-lib.sh
+
+create_archive_file_with_config () {
+	local file="$1" &&
+	local config="$2" &&
+	shift 2 &&
+
+	test_when_finished "rm -rf \"$file\"" &&
+	git -c tar.tgz.command="$config" archive -o "$file" HEAD
+}
+
+setup_gzip_vs_git_archive_gzip () {
+	create_archive_file_with_config "expect.tgz" "gzip -cn" &&
+	create_archive_file_with_config "actual.tgz" "git archive gzip"
+}
+
+test_lazy_prereq GZIP_TRIVIALLY_STABLE '
+	git clone "$TRASH_DIRECTORY" . &&
+	test_commit P &&
+	setup_gzip_vs_git_archive_gzip &&
+	test_cmp_bin expect.tgz actual.tgz
+'
+
+if ! test_have_prereq GZIP_TRIVIALLY_STABLE
+then
+	skip_all='skipping gzip v.s. git archive gzip tests, even trivial content differs'
+	test_done
+fi
+
+# The first test_expect_success is after the "skip_all" so we'll get
+# the skip summary in prove(1) output.
+test_expect_success 'setup' '
+	test_commit A
+'
+
+test_expect_success GZIP '"gzip -cn" and v.s. "git archive gzip" produce the same output still' '
+	setup_gzip_vs_git_archive_gzip &&
+	test_cmp_bin expect.tgz actual.tgz
+'
+
+generate_objects () {
+	i=$1
+	iii=$(printf '%03i' $i)
+	{
+		echo $iii &&
+		test-tool genrandom "$iii" 8192
+	} >file_$iii &&
+	git update-index --add file_$iii
+}
+
+test_expect_success 'create objects with (stable) random data' '
+	test_commit initial &&
+	for i in $(test_seq 1 5)
+	do
+		generate_objects $i || return 1
+	done &&
+	git commit -m"add objects"
+'
+
+test_expect_success GZIP '"gzip -cn" and v.s. "git archive gzip" have differing output' '
+	setup_gzip_vs_git_archive_gzip &&
+	! test_cmp_bin expect.tgz actual.tgz
+'
+
+test_done
-- 
2.39.1.1392.g63e6d408230


  parent reply	other threads:[~2023-02-02  9:33 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-31  0:06 Stability of git-archive, breaking (?) the Github universe, and a possible solution Eli Schwartz
2023-01-31  7:49 ` Ævar Arnfjörð Bjarmason
2023-01-31  9:11   ` Eli Schwartz
2023-02-02  9:32   ` [PATCH 0/9] git archive: use gzip again by default, document output stabilty Ævar Arnfjörð Bjarmason
2023-02-02  9:32     ` [PATCH 1/9] archive & tar config docs: de-duplicate configuration section Ævar Arnfjörð Bjarmason
2023-02-02  9:32     ` [PATCH 2/9] git config docs: document "tar.<format>.{command,remote}" Ævar Arnfjörð Bjarmason
2023-02-02  9:32     ` [PATCH 3/9] archiver API: make the "flags" in "struct archiver" an enum Ævar Arnfjörð Bjarmason
2023-02-02  9:32     ` [PATCH 4/9] archive: omit the shell for built-in "command" filters Ævar Arnfjörð Bjarmason
2023-02-02  9:32     ` [PATCH 5/9] archive-tar.c: move internal gzip implementation to a function Ævar Arnfjörð Bjarmason
2023-02-02  9:32     ` [PATCH 6/9] archive: use "gzip -cn" for stability, not "git archive gzip" Ævar Arnfjörð Bjarmason
2023-02-02  9:32     ` [PATCH 7/9] test-lib.sh: add a lazy GZIP prerequisite Ævar Arnfjörð Bjarmason
2023-02-02  9:32     ` Ævar Arnfjörð Bjarmason [this message]
2023-02-02  9:32     ` [PATCH 9/9] git archive docs: document output non-stability Ævar Arnfjörð Bjarmason
2023-02-02 10:25       ` brian m. carlson
2023-02-02 10:30         ` Ævar Arnfjörð Bjarmason
2023-02-02 16:34         ` Junio C Hamano
2023-02-04 17:46           ` brian m. carlson
2023-02-02 16:17     ` [PATCH 0/9] git archive: use gzip again by default, document output stabilty Phillip Wood
2023-02-02 16:40       ` Junio C Hamano
2023-02-03 13:49       ` Ævar Arnfjörð Bjarmason
2023-02-06 14:46         ` Phillip Wood
2023-02-03 15:47       ` Theodore Ts'o
2023-02-02 16:25     ` Junio C Hamano
2023-02-04 18:08       ` René Scharfe
2023-02-05 21:30         ` Ævar Arnfjörð Bjarmason
2023-02-12 17:41           ` René Scharfe
2023-02-02 19:23     ` Raymond E. Pasco
2023-02-03  8:06       ` [PATCH] archive: document output stability concerns Raymond E. Pasco
2023-01-31  9:54 ` Stability of git-archive, breaking (?) the Github universe, and a possible solution brian m. carlson
2023-01-31 11:31   ` Ævar Arnfjörð Bjarmason
2023-01-31 15:05   ` Konstantin Ryabitsev
2023-01-31 22:32     ` brian m. carlson
2023-02-01  9:40       ` Ævar Arnfjörð Bjarmason
2023-02-01 11:34         ` demerphq
2023-02-01 12:21           ` Michal Suchánek
2023-02-01 12:48             ` demerphq
2023-02-01 13:43               ` Ævar Arnfjörð Bjarmason
2023-02-01 15:21                 ` demerphq
2023-02-01 18:56                   ` Theodore Ts'o
2023-02-02 21:19                     ` Joey Hess
2023-02-03  4:02                       ` Theodore Ts'o
2023-02-03 13:32                         ` Ævar Arnfjörð Bjarmason
2023-02-01 23:16         ` brian m. carlson
2023-02-01 23:37           ` Junio C Hamano
2023-02-02 23:01             ` brian m. carlson
2023-02-02 23:47               ` rsbecker
2023-02-03 13:18                 ` Ævar Arnfjörð Bjarmason
2023-02-02  0:42           ` Ævar Arnfjörð Bjarmason
2023-02-01 12:17       ` Raymond E. Pasco
2023-01-31 15:56   ` Eli Schwartz
2023-01-31 16:20     ` Konstantin Ryabitsev
2023-01-31 16:34       ` Eli Schwartz
2023-01-31 20:34         ` Konstantin Ryabitsev
2023-01-31 20:45         ` Michal Suchánek
2023-02-01  1:33     ` brian m. carlson
2023-02-01 12:42   ` Ævar Arnfjörð Bjarmason
2023-02-01 23:18     ` brian m. carlson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=patch-8.9-62c796da4e2-20230202T093212Z-avarab@gmail.com \
    --to=avarab@gmail.com \
    --cc=demerphq@gmail.com \
    --cc=eschwartz93@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=l.s.r@web.de \
    --cc=msuchanek@suse.de \
    --cc=ray@ameretat.dev \
    --cc=sandals@crustytoothpaste.net \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.