From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: demerphq <demerphq@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
Raul E Rangel <rrangel@chromium.org>,
git@vger.kernel.org
Subject: Re: Feature request: Add --mtime option to git archive
Date: Sat, 18 Feb 2023 17:08:28 +0000 [thread overview]
Message-ID: <Y/EFfxe0GGqnipvL@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <CANgJU+VaF7-SJgGPqYGEV5VcJd_nTt2SMOQ5u9mNZ_wsArKT6g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]
On 2023-02-18 at 03:04:12, demerphq wrote:
> I could understand this position if letting the user set the --mtime
> implied some harm that must be mitigated, but it seems like an odd
> choice if there is none. Especially given it would also future proof
> git against people coming up with a good reason not to use the 0 epoch
> in the future that you haven't thought of right now. It is not like
> epoch's and unix time have a totally uncontroversial and stable
> history. 0 has meant multiple dates over time, and the current
> definition of 1 Jan 1970, 00:00:00 UTC is problematic as UTC didn't
> exist until 1972! Given it clearly wouldn't be hard to allow users to
> select the epoch in these archives then why not do so?
If folks want such an option, they're welcome to send a patch to do
that. My approach is providing a stable tar format that doesn't change,
and for people who want to use that format, it has fixed timestamps for
trees (so it's completely rigid). If people want to use the default
format with an arbitrary timestamp, that's fine, and we can support
that, but we won't guarantee that that format won't change its
serialization in the future.
> I have seen devs have issues with stuff like this in the past.
> Unpacking an archive on one machine showing a different date than one
> another, or other weird artifacts. Mac used to use a different 0 epoch
> than windows and linux as I recall, etc etc. I dont remember the gory
> details, but i have definitely seen people gnash their teeth over
> these kind of decisions before. Why not side-step that if you can and
> let people choose their own defaults?
The ustar format is defined by POSIX and uses the Unix epoch, just like
the zip format has its own epoch. If you're processing a tar archive,
you need to use the Unix epoch.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2023-02-18 17:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-16 19:41 Feature request: Add --mtime option to git archive Raul E Rangel
2023-02-16 21:05 ` Jeff King
2023-02-16 22:21 ` Junio C Hamano
2023-02-17 0:50 ` Jeff King
2023-02-17 2:04 ` Junio C Hamano
2023-02-17 15:43 ` Raul Rangel
2023-02-17 20:31 ` René Scharfe
2023-02-17 20:25 ` Jeff King
2023-02-18 3:04 ` demerphq
2023-02-18 17:08 ` brian m. carlson [this message]
2023-02-18 8:36 ` [PATCH] archive: add --mtime René Scharfe
2023-02-18 17:25 ` Junio C Hamano
2023-02-19 10:44 ` René Scharfe
2023-02-21 5:37 ` Junio C Hamano
2023-02-22 19:51 ` Jeff King
2023-02-22 23:23 ` 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=Y/EFfxe0GGqnipvL@tapette.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=demerphq@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=rrangel@chromium.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 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).