From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, Emily Shaffer <emilyshaffer@google.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
Jason Pyeron <jpyeron@pdinc.us>
Subject: Re: [PATCH 4/4] docs: note that archives are not stable
Date: Sun, 28 Feb 2021 18:19:48 +0000 [thread overview]
Message-ID: <YDvexO2NFM0KZ1Jo@camp.crustytoothpaste.net> (raw)
In-Reply-To: <87h7lwl5mv.fsf@evledraar.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]
On 2021-02-28 at 12:48:56, Ævar Arnfjörð Bjarmason wrote:
> Perhaps something like this instead:
>
> The output of 'git archive' is guaranteed to be the same across
> versions of git, but the archive itself is not guaranteed to be
> bit-for-bit identical.
>
> In practice the output of 'git archive' is relatively stable across
> git versions, but has changed in the past, and most likely will in
> the future.
>
> Since the tar format provides multiple ways to encode the same
> output (ordering, headers, padding etc.) you should not rely on
> output being bit-for-bit identical across versions of git for
> e.g. GPG signing a SHA-256 hash of an archive generated with one
> version of git, and then expecting to be able to validate that GPG
> signature with a freshly generated archive made with same arguments
> on another version of git.
I think something like this is good. I'm a bit nervous about telling
people that the output is relatively stable because that will likely
push people in the direction that we don't want to encourage. I might
rephrase the first two paragraphs as so:
The output of 'git archive' is guaranteed to be the same across
versions of git, but the archive itself is not guaranteed to be
bit-for-bit identical. The output of 'git archive' has changed
in the past, and most likely will in the future.
I'm not very familiar with the zip format, but I assume that it also has
features that allow equivalent but not bit-for-bit equal archives.
Looking at Wikipedia leads me to believe that one could indeed create
different archives just by either writing a Zip64 record or not, and if
we store the SHA-1 revision ID in a comment, then we would also produce
a different archive when using an equivalent SHA-256 repo. And of
course there's compression, which allows many different but equivalent
serializations. So we'd probably need to say the same thing about zip
files as well.
--
brian m. carlson (he/him or they/them)
Houston, Texas, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2021-02-28 18:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-27 19:18 [PATCH 0/4] Documentation updates to FAQ and git-archive brian m. carlson
2021-02-27 19:18 ` [PATCH 1/4] docs: add a question on syncing repositories to the FAQ brian m. carlson
2021-02-28 13:01 ` Ævar Arnfjörð Bjarmason
2021-03-15 20:40 ` brian m. carlson
2021-02-27 19:18 ` [PATCH 2/4] docs: add line ending configuration article to FAQ brian m. carlson
2021-02-27 19:18 ` [PATCH 3/4] docs: add a FAQ section on push and fetch problems brian m. carlson
2021-02-28 12:37 ` Ævar Arnfjörð Bjarmason
2021-02-28 18:07 ` brian m. carlson
2021-03-01 18:02 ` Junio C Hamano
2021-02-27 19:18 ` [PATCH 4/4] docs: note that archives are not stable brian m. carlson
2021-02-28 12:48 ` Ævar Arnfjörð Bjarmason
2021-02-28 18:19 ` brian m. carlson [this message]
2021-02-28 18:46 ` Ævar Arnfjörð Bjarmason
2021-03-01 18:15 ` Junio C Hamano
2021-03-03 0:36 ` brian m. carlson
2021-03-03 6:55 ` Junio C Hamano
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=YDvexO2NFM0KZ1Jo@camp.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=avarab@gmail.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=jpyeron@pdinc.us \
--cc=konstantin@linuxfoundation.org \
/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.