git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "René Scharfe" <l.s.r@web.de>, "Jason Pyeron" <jpyeron@pdinc.us>,
	git@vger.kernel.org
Subject: Re: git archive setting user and group
Date: Fri, 22 Jan 2021 23:58:19 -0500	[thread overview]
Message-ID: <YAus63jWBP1fIAhf@coredump.intra.peff.net> (raw)
In-Reply-To: <YAt2PPM4HRcKva9a@camp.crustytoothpaste.net>

On Sat, Jan 23, 2021 at 01:05:00AM +0000, brian m. carlson wrote:

> > Right now, "git archive" operations are bit-for-bit identical across all
> > versions going back at least 8+ years. In fact, we've been relying on this to
> > support bundling tarball signatures with git tags themselves (via git notes).
> > E.g. you can see this in action here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tag/?h=v5.10.9
> > 
> > If you click on "(sig)", you will download a signature that can be used to
> > verify the tarball generated using "git archive".
> 
> Please do not rely on this behavior.  I want to state in the strongest
> possible terms that this is not guaranteed behavior and it may change at
> any time.  We have explicitly said so on the list multiple times.  If
> you need reproducible archives, you need to add a tool to canonicalize
> them in a suitable format and not rely on Git to never change things.

I strongly second this. :)

It's also not quite true that things have remained bit-for-bit identical
for all that time. We have fixed bugs in that time, although they do not
always cause a change in every output tarball (they often depend on
corner cases like having long pathnames). Two off the top of my head
(that have indeed caused people to complain about changing checksums):

  - 22f0dcd963 (archive-tar: split long paths more carefully,
    2013-01-05)

  - 82a46af13e (archive-tar: fix pax extended header length calculation,
    2019-08-17)

We also rely on system gzip. That's pretty stable, but I have heard tell
that even `gzip -n` may differ on platforms.

Another fun one I saw recently: using export-subst with $Format:%h$ will
produce different results depending on how many objects are present in
the repository running git-archive.

-Peff

  reply	other threads:[~2021-01-23  4:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22 20:40 git archive setting user and group Jason Pyeron
2021-01-22 21:00 ` René Scharfe
2021-01-22 21:13   ` Jason Pyeron
2021-01-22 21:39   ` Konstantin Ryabitsev
2021-01-22 22:02     ` Jason Pyeron
2021-01-22 22:28     ` Ævar Arnfjörð Bjarmason
2021-01-23  1:05     ` brian m. carlson
2021-01-23  4:58       ` Jeff King [this message]
2021-01-23  5:16         ` Konstantin Ryabitsev
2021-01-23  5:11       ` Konstantin Ryabitsev
2021-01-22 22:29   ` Junio C Hamano
2021-01-22 22:51     ` Jason Pyeron
  -- strict thread matches above, loose matches on Subject: below --
2021-01-22 20:09 Jason Pyeron

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=YAus63jWBP1fIAhf@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jpyeron@pdinc.us \
    --cc=l.s.r@web.de \
    --cc=sandals@crustytoothpaste.net \
    /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 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 NNTP newsgroup(s).