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

[Jeff King <peff@peff.net>]

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

> >> 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