Re: Feature request: Add --mtime option to git archive

From: Jeff King <peff@peff.net>
Date: Feb 17, 2023, 00:50 UTC
Message-ID: <Y+7PcqpYhF5ZuApG@coredump.intra.peff.net>
In-Reply-To: <xmqq5yc1p7yn.fsf@gitster.g>

On Thu, Feb 16, 2023 at 02:21:36PM -0800, Junio C Hamano wrote:

Show 10 quoted lines

> >> When generating a tarball with `git archive <tree>`, `git archive` will
> >> use the current time as the mtime. This results in a non-hermetic
> >> tarball. Could we should add a --mtime option that allows passing in
> >> the time? 
> >
> > That seems like a very reasonable feature to have. Just to sketch out
> > the implementation, in case anybody wants to work on it: ...
> 
> There has been a discussion on not just "fix mtime" but coming up
> with a lot more stable tar archive format specification.

Yes, I think in brian's proposal the mtime would always be 0. I don't mind that either (and really, I doubt anybody would really want to set --mtime to anything but a fixed, known value anyway). This is a much smaller change that could be done in the meantime with less effort, but I guess we'd be stuck with --mtime forever, then.

A similar option in is to simply start using "0" in the meantime, like:

diff --git a/archive.c b/archive.c
index 81ff76fce9..48d89785c3 100644
--- a/archive.c
+++ b/archive.c
@@ -470,7 +470,7 @@ static void parse_treeish_arg(const char **argv,
 		archive_time = commit->date;
 	} else {
 		commit_oid = NULL;
-		archive_time = time(NULL);
+		archive_time = 0;
 	}
 
 	tree = parse_tree_indirect(&oid);

Nobody will complain about changing the byte-for-byte format, since by definition it
was already changing once per second (cue somebody complaining that they
have been using LD_PRELOAD tricks to simulate --mtime).

I do wonder if people would complain (both with the patch above and with
brian's proposal) that the resulting tarballs extract everything with a
date in 1970. That's not functionally a problem, but it looks kind of
weird in "ls -l".

-Peff