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:22 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
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).