From: Junio C Hamano <gitster@pobox•com>
To: "brian m. carlson" <sandals@crustytoothpaste•net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail•com>,
"Konstantin Ryabitsev" <konstantin@linuxfoundation•org>,
"Eli Schwartz" <eschwartz93@gmail•com>,
"Git List" <git@vger•kernel.org>
Subject: Re: Stability of git-archive, breaking (?) the Github universe, and a possible solution
Date: Wed, 01 Feb 2023 15:37:19 -0800 [thread overview]
Message-ID: <xmqqh6w5x8i8.fsf@gitster.g> (raw)
In-Reply-To: <Y9ry5Wxck4s/X2B+@tapette.crustytoothpaste.net> (brian m. carlson's message of "Wed, 1 Feb 2023 23:16:53 +0000")
"brian m. carlson" <sandals@crustytoothpaste•net> writes:
> I don't think a blurb is necessary, but you're basically underscoring
> the problem, which is that nobody is willing to promise that compression
> is consistent, but yet people want to rely on that fact. I'm willing to
> write and implement a consistent tar spec and to guarantee compatibility
> with that, but the tension here is that people also want gzip to never
> change its byte format ever, which frankly seems unrealistic without
> explicit guarantees. Maybe the authors will agree to promise that, but
> it seems unlikely.
Just to step back a bit, where does the distinction between
guaranteeing the tar format stability and gzip compressed bitstream
stability come from? At both levels, the same thing can be
expressed in multiple different ways, I think, but spelling out how
exactly the compressor compresses is more involved than spelling out
how entries in a tar archive is ordered and each entry is expressed,
or something?
> That would probably break things, because gzip is GPLv3, and we'd need
> to ship a much older GPLv2 gzip, which would probably differ from the
> current behaviour, and might also have some security problems.
Yup, security issues may make bit-for-bit-stability unrealistic.
IIRC, the last time we had discussion on this topic, we settled
on stability across the same version of Git (i.e. deterministic
result)?
next prev parent reply other threads:[~2023-02-01 23:37 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 ` [PATCH 8/9] archive tests: test for "gzip -cn" and "git archive gzip" stability Ævar Arnfjörð Bjarmason
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-02 19:23 ` Raymond E. Pasco
2023-02-03 8:06 ` [PATCH] archive: document output stability concerns Raymond E. Pasco
2023-02-03 13:49 ` [PATCH 0/9] git archive: use gzip again by default, document output stabilty Æ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-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 12:17 ` Raymond E. Pasco
2023-02-01 23:16 ` brian m. carlson
2023-02-01 23:37 ` Junio C Hamano [this message]
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-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=xmqqh6w5x8i8.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=avarab@gmail$(echo .)com \
--cc=eschwartz93@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=konstantin@linuxfoundation$(echo .)org \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox